Documentation of weather Bus

[mlauster]

It would be very helpful to have an overview in the weather Bus info or in the ReaderTMY3 info that lists all values contained in the Bus. ReaderTMY3 info contains a list, is this a complete list or are these only the variables for which the user can choose the source (file, parameter or input)?

[mwetter]

I agree that such a list would be good to add to the reader. Can you please make the required changes to the documentation?
In addition, it would be good to group in weaBus variables that are similar. For example, it would be convenient if all temperatures are listed after each other rather than interspersed with other variables. Maybe this could be done by changes the order of the connect statements.

[mlauster]

I added a table with all possible outputs to ReaderTMY3.
Regarding the order of variables in weaBus, it seems that they are arranged in alphabetical order. So grouping is already quite okay, only radHorIR is not grouped with the other radiations as they are named H.... We could rename radHorIR to HIRHor, if H covers that kind of radiation.

Some variables seem to have no unit (at least none is visible in weaBus) and some descriptions are not really descriptive. I tried to track down where the descriptions and units originate from but came to no clear solution. It might be the first definition of the variable, e.g. "Horizontal global radiation" for HGloHor originates from BoundaryConditions.SolarIrradiation.BaseClasses.DiffuseIsotropic and "Output temperature" for TBlaSky comes from BoundaryConditions.WeatherData.BaseClasses.CheckTemperature. Does somebody sees a possibility to overwrite these definitions? "Connector of Real output singal" for lat and lon originates from Modelica-Blocks.Sources, so no good idea to just change the first definition.

One last thing is this qute little symbol in weaBus that indicates if the variable is an input or output. Currently, we have a mixture of both. We actually should only have outputs. However, there is no clear relation to the definition of outputs within ReaderTMY3. For me it seems random if a variable is shown as input or output. Does somebody knows how Dymola choose these little symbols?

[mwetter]

@mlauster
I corrected some of your highlighted issues, but not yet "Declination" and "Output temperature", in 2ec7831.

I could go either way with radHorIR.

I don't know why nOpa has no units while nTot has units. I do not see a difference in implementation between the two.

[mlauster]

@mwetter
Do you see a way to change "Declination" and "Output temperature"?
Then I propose changing radHorIR to HIRHor. Anybody fine with this? This might make it necessary to reconnect ReaderTMY3 in high-level models if somebody used radHorIR. We are currently not using conversion scripts, do we?

[mwetter]

@mlauster
The documentation string in the weather bus seems to be obtained from some output or input signal that is connected to the weather bus. For example, for the solar declination, if you change in BaseClasses.ZenithAngle the comment of the input signal decAng, then this will be reflected in the weather data bus. For other signals, it uses the output signal that is connected in the weather data reader. I have not found a pattern for when which signal is used. This also explains the arrow symbol (input vs. output).

I made a new ticket to treat a potential bug separately
#382

I am fine with renaming radHorIR to HIRHor" but would preferHHorIRbecause other models we use put theIRorSol` as the ending of the variable name.

[mlauster]

Dymola even states where it gets units, description and arrow symbol from, see example. But it still seems to have no clear pattern. It might be some "shortest connection (min number of connect-statements) to weaBus that holds necessary information". I could ask Modelon for more information. Anyway, I'm also happy to keep it as it is and focus on other stuff.

I fixed units of nOpa, it originates from BoundaryConditions.SkyTemperature.BlackBody.

I changed the name of radHorIR to HHorIR, somehow this changing of the name changed the origination of the description etc. in weaBus. It originated from BoundaryConditions.SkyTemperature.BlackBody and now is from BoundaryConditions.WeatherData.BaseClasses.CheckRadiation. Weird stuff... . Anyway, now the description is "Radiation" instead of "Horizontal infrared irradiation". @mwetter, do you know a way to fix that?

[mwetter]

@mlauster If the comment is now picked up from CheckRadiation, then I see the only way to make a new protected block as I did for Latitude and use this instead of CheckRadiation.

I don't think there is much benefit in tracking down the rules for which description it picks up.