Help on estimated cloudbase height coding

[PK]

Hello

Since the gliding season is coming, I thought it would be interesting
to watch the estimated Cumulus cloud base height above ground (station
height), both current value and displayed in a separate diagram.

I could add a class CloudBaseFormula in wfcommon/formula/temp.py, but
then I wonder:

- are stored values always in degC,
and is it ok to calculate only in meters?

- how could values stationHeight and cloudBase be accessed from the
web page (in main.html)?

- I assume that cloudBase values do not need to be stored in the
database, but is calculated from database values when rendered?
Should wfrender/datasource/accumulator.py and wfcommon/formula/
__init__.py can be extended to cover cloudBase also?

- should cloudBase height code be separated out or be commented out in
the trunk version in the future?

- where else should I look to get this working?

Thanks for any help
/PK

[Jordi Puigsegur Figueras]

Hello

> I assume that cloudBase values do not need to be stored in the 

> database, but is calculated from database values when rendered?

Yes, this is the way. All formulas are calculated on the fly (the only exception to this rule is the dew point which is saved in the database).

> I could add a class CloudBaseFormula in wfcommon/formula/temp.py

Yep, that's the right thing to do. The temp.py formulas are good examples to follow. You must take into accound that since we don't have scalar functions yet we always need to add a max/min/avg aggregation layer because the function will be applied to sets of data and will be expected to return a single value. Once you have the new function the rest is a matter of configuring wfrog renderer via yaml files.

> Should wfrender/datasource/​accumulator.py and wfcommon/formula/

> __init__.py can be extended to cover cloudBase also?

accumulator.py does not need to be changed. Once the formula is implemented all configuration is done through yaml files.

You need to declare a yaml key for the new formula in __init__.py.

> are stored values always in degC,

 

Values in the database are always in metric units (degC). 

> and is it ok to calculate only in meters?

If you want to let people choose different units you'll need to create a new units entry and the formula you'll create needs to do the necessary conversions. I'll probably leave that part until you have a version with m. working properly.

 

> how could values stationHeight and cloudBase be accessed from 

> the web page (in main.html)?

Station height is a fixed value. I think it can be included in a similar way as the station driver name. To include another graphic you need to configure it through yaml files in a similar ways as tempInt or temp2 are added.

> should cloudBase height code be separated out or be commented out in

> the trunk version in the future?

As I see it, it would be something optional (like tempInt or HeatIndex) that would not interfere with the standard wfrog setup.

Best regards,

Jordi.

[PK]

Thanks for encouraging hints.

Thus, I update:

- temp.py: CloudBaseFormula(object) with init, append, value

- __init__.py with YamlCloudBaseFormula

but are more functions needed for "max/min/avg aggregation"?

Could you explain "since we don't have scalar

functions yet we always need to add a max/min/avg aggregation layer
because the function will be applied to sets of data and will be

expected to return a single value"?

Thanks
/PK
On 23 mar, 10:14, Jordi Puigsegur Figueras <jordi.puigse...@gmail.com>
wrote:

[Jordi Puigsegur Figueras]

Hi,

Thus, I update:

- temp.py: CloudBaseFormula(object) with init, append, value

- __init__.py with YamlCloudBaseFormula

but are more functions needed for "max/min/avg aggregation"?

Could you explain "since we don't have scalar

functions yet we always need to add a max/min/avg aggregation layer
because the function will be applied to sets of data and will be

expected to return a single value"?

You cannot simply write a CloudBaseFormula that takes a single sample and produces a scalar value, i.e. the cloud base value in m. You need to decide which aggregation is the right one and mix both the cloud base function and the aggregation function in a single function (like the other examples in temp.py). 

Aggregator will run that function on sets of data (depending on its slice setting). E.g.:

- !Windchill is a combination of windchill formula plus a min aggregation function.

- !humidex is a combination of humidex formula plus a max aggregation function.

Just have a look at the formulas in temp.py and see how they first calculate the values and then keep either the minimum or the maximum.

Jordi.

[PK]

Have not had time yet, but will.

Here is a weather station with cloud base height (Molnbas):
http://vader.vadstenastad.se/index22vader.php

Translation of the explaining text:
Cloud base height is the height where clouds can form.

CU
/PK
On 23 mar, 22:22, Jordi Puigsegur Figueras <jordi.puigse...@gmail.com>
wrote: