cstb/citygml-energy

Version 0.9.0, first draft

Closed this issue · 20 comments

JoachimBenner commented

I finalized a first draft of the next version EnergyADE 0.9.0,

The following issues have been regarded in the new data model: #118, #119, #133, #135, #136 and #137

There are three other open issues concerning the EnergySystem (#123, #124 and #134) where obviously there is not yet a hamonized solution within the Energy System working group. As soon as a proposal from the working group exists, I can try to integrate it into the new version.

The same is applies for issue #138, up to now I do not totally understand it.

EnergyADE_0_9_0.zip

gioagu commented

Hi,

some notes/suggestions here regarding the 0.9 proposal so far:

  1. BuildingPhysics module

For representation coherency, connect ADE Abstractbuilding to _AbstractConstruction, like already done with ThermalBoundary and ThermalOpening.

The enumeration values of HeightAboveGround have the first letter not capital, unlike all other enumrations/codelists

Simplify/reduce the name of some attributes. E.g.
In class RefurbishmentMeasure, rename dateOfRefurbishment to simply date, descriptionOfRefurbishment to simply Description.
I would suggest the same also in class EnergyPerformanceCertification with attributes name and rating

  1. Energy System module

What is the role of relation "correspondsTo" between EnergyDemand and _CityObject? To me it does not make sense, maybe an intentional leftover?

In EnergyConversionSystem, rename "number" to "serialNumber", as the semantics is otherwise not clear enough.

Proposal: so far, if in a building there are multiple EnergyConversionSystems installed, we can model them as a whole in that we define to total nominalIntalledPower. I would proposed to add an (optional) attribute stating the numberOfInstalledDevices: integer [0..1]
In this way I could say that in a building I know that there are x devices, with a total installed power of y, although I do not know exactly where they are. Question: would it make sense to move this two attributes to the parent class?

The attribute "productAndInstallationDocument" in EnergySystem is now redundant, as the class has become now itself a _CityObject.

So far all from my side, I will get back if I find something else.

RomainNouvel commented

I agree on most of Giorgio propositions, except:

  • serial number: the attribute "number" was meant to represent the number of identical energy conversion systems installed (5 radiators, 2 heat pumps, 4 gas boilers...) in order to model them just with 1 class. Actually, it's was you later call numberOfinstalledDevices (we can rename it more explicitly if you want). For the serial number, we already have the attribute model. If the definitions are not precise enough, we must make them more explicit!
JoachimBenner commented

Hello,

some comments to Giorgios and Romains proposals:

Building Physics module:

  • There is already the attribute aggregatedBuildingConstruction, enabling to relate an AbstractConstruction with a Building

  • I agree that the enumeration ElevationReferenceValue should be consistent with the other ones, i.e. the values should start with a capital letter.

  • I also agree on the shortening of property names in cases where the semantics is implicitly defined by the dataType or featureType name.

Energy System module

  • We have the relation energyDemand, enabeling any _CityObject to address an EnergyDemand.

  • correspondsTo is the inverse of this relation, which means it is in principle redundant. However, there are a lot of other bilateral n:m relation in the Energy Module. I know that this kind of modelling is always problematic for database schemata, and therefore I am open to discuss this part of the model. From my point of view, esp. the relation correspondsTo (EnergyDemand --> _CityObject) is not really needed.

  • number already is a property of the base class _EnergySystem. I think, we should rename number to numberOfDevices, and introduce a new, optional property serialNumber (type CharacterString) of _EnergySystem.

  • I think we all agree to eliminate the attribute productAndInstallationDocument (_EnergySystem), and to change EnergyDistributionSystem into an abstract class.

RomainNouvel commented

Concerning the relation correspondsTo (EnergyDemand --> _CityObject):

  • We modeled double relations between "EnergyConversionSystem" and "EnergyFlow" which allow us to cross the models either from Consumer perspective (isStored, isDistributed, isEmitted, isProvided) or from Provider perspective (stores, distributes, emits, provides). The latter is uncomplete (and useless) if we don't have the last relations going from _EnergySystem to EnergyDemand and from EnergyDemand to CityObject. To remain coherent with this concept, I would keep the relation EnergyDemand -> CityObject bur rename it more explicitly ("energyDemandOf", "demandedBy"...)
  • The EnergyDemand is covered by an EnergyFlow (generally emitted by an emitter, but not only in our model). Therefore, I would delete the relation EnergyDemand -> _EnergySystem, and either add a double relation "covers" / "isCovered" between EnergyFlow and EnergyDemand, or make EnergyDemand inherits from EnergyFlow (because EnergyDemand and EnergyFlow have almost the same parameters). I would suggest the latest version
JoachimBenner commented

I must confess that I do not fully understand the concepts of EnergyDemand and EnergyFlow. If I understand you correct, you propose to define EnergyDemand as a specialization of EnergyFlow. Is this consistent with the actual definitions of the two classes?

EnergyDemand:

Energy demand is the useful energy required to satisfy a specific end-use, such as heating, cooling, domestic hot water etc.

EnergyFlow

Energy form containing the energy, occuping intermediate steps in the energy-supply chain between primary energy sources and end-use demands

By the way, especially in the Energy Systeme module a lot of definitions are still missing.

RomainNouvel commented

@JoachimBenner : We supply Energy (EnergyFlow) to answer the EnergyDemand. I would indeed propose to define EnergyDemande as a specialization of EnergyFlow. I would see EnergyFlow like the "general form of energy" going through the different steps of the energy supply chain.

Then I would slightly adapt the definition of EnergyFlow:
Energy Form which contains the energy at the different steps of the energy-supply chain, from the primary energy sources to the end-use demands.

Furthermore, it does not make sence, I think, to give a CO2EmissionFactor and primaryEnergyFactor for the EnergyDemand or for the intermediate steps of the energy-supply chain. This must be only given for the "final" (or source) form of energy. I would therefore propose the following changes:

  • replacing EnergyCarrier in EnergyDemand and EnergyFlow by the codelist 'EnergyCarrierType', which contains our present EnergySourceValue (actually EnergyCarrierTypeValue
  • I would create a class EnergySource, specialization of EnergyFlow, which contains all the parameters of the present EnergyCarrier. Definition : Form of Energy at the source of building energy supply chain (electricity, fossil fuels, renewable energy etc.)
  • I would delete EnergyCarrier
JoachimBenner commented

Here is version 2 of the data model, where I tried to take into account Romain's proposals for the Energy System module, which again increased the complexity. I more and more doubt whether its really makes sense to permanently produce new versions of the Energy System module, while obviously noone really needs, uses and implements it.

Sorry to say, but also my time to be spent for the Energy ADE is limited. Thus, please let us come to an end with version 0.9.0. In the zip archive you also find the feature catalogue, and an Excel tabel showing all existing (and also the missing) definitions.

EnengyADE_0_9_0_V2.zip

RomainNouvel commented

Nice job on the EnergySystem module! Few remarks about the wording:

  • Let's rename Emitter -> EmitterSystem to stay coherent with the naming of the other classes inheriting from _EnergySystem
  • Let's name the same the parameter power of EnergyConversionSystem and Emitter -> installedPower (or both installedNominalPower)
  • please rename the parameter energyCarrier (of EnergyFlow) -> energyCarrierType and the codeList EnergySourceValue -> EnergyCarrierTypeValue
  • serialNumver -> serialNumber (is this parameter really important for EnergyADE @gioagu, or does th model information are enough ?)
RomainNouvel commented

@jaykae26, @silviacoccolo and @mlauster , what are your opinion on the new EnergySystem structure? For the next guidelines, we'll have to illustrate it with some concrete cases. Do you want to have a call to discuss about it?

gioagu commented

Hi,
thank you for uplading the 2nd version!
In general, I agree with the proposed changes by Romain (see above).
Some remarks from my side as well, mostly cosmetics:

  1. Building Physics:
    To keep in line with simplifying a bit some attibute names, I would propose to reduce the
    "refurbishmentMeasureOnBuilding" and "...OnThermalBounday" to just "refurbishmentMeasure", as it is clear to what they refer being in the list of properties of the class.

  2. EnergySystems:

  • no need for "serialNumber" in class _EnergySystem", as it is already covered by property "model" (see above @RomainNouvel)

  • in order to convey a better feeling of "booleanness" in some attributes (and coherently with other cases already in the Energy ADE), I would propose to rename
    a) in "Boiler": condensation to hasCondensation
    b) in "MechanicalVentilation": heatRecovery to hasHeatRecovery
    c) in "Emitter" ( soon to be EmiterSystem), does the attribute "unitNumber" correspond to numberOfInstalledDevices, or model, or something else? In the first two cases, it is redundant because the same attribute is now inherited from _EnergySystem. If so, please remove.

d) In the SolarThermalSystem (and the PVSystem), there was a proposal to rename eta0, a1 and a2. Was this accepted?

  1. Schedules:
    I think we could add the boolean attribute to PeriodOfYear: "isLeapYear":Boolean[0..1] in order to define whether the referred year is 355 or 356 days long.

I would also appreciate a general comment to this whole "new" structure of the Energy Systems module from our specialists in the WG (and not only).

RomainNouvel commented

c) Indeed, unitNumber refered previously to the number of devices. It is now obsolete in EmitterSystem
d) I think so. Do you remember @mlauster ?
3. Wow! Maybe we should agree (and write explicitly in the definition) that the defined schedules are only defined for non leap year to make it easier... if we define some schedule for both leap year and non leap year, we will become crazy!

Maybe our colleagues of LBNL have also some remarks on the structure of this new version?

mlauster commented

@JoachimBenner, thanks a lot for your work, I can only imagine the effort to bring all our loose thoughts of so many modules into one structure. And I agree, it gets more and more complex and the next time before we start to restructure it again, we need clear use cases and justifications for all modifications. However, for the EnergySystem module, if feel that this new version is a big step forward as we do not try to model something flexible like energy system (including generation, distribution and consumption) in some kind of hierarchical model. _EnergySystem and EnergyFlow are of high value and the new core elements of that module! I really endorse the current process of refining and checking the current proposal by the information experts like @RomainNouvel and @gioagu, but do not feel to have the expertise to support them. So far, I support all renamings and deletions, etc.
To the open individual questions:
d) #134 is still open and awaits your Request of Change, @RomainNouvel. :) Though, I am not quite sure what is was about. Did you want to change the units or rename the parameters? Because parameter names seem to be as you propose.

Thanks all for the fruitful discussions!

RomainNouvel commented

Done. It was about both.

JoachimBenner commented

Building Physics module

We obviously agree that the property names refurbishmentMeasureOf... shall be shortend

Energy System module

I ask the Energy System WG to provide a verified and complete list of changes with respect to the last version (EnergyADE_0_9_0_V2). As soon as this list is available, I will integrate the final changes into the UML model.

Schedules

The central problem with time series and schedules has only indirectly to do with leap years. In the EnergyADE, we use the ISO types for time instances (TM_Position) and time periods (TM_Period). These data types always specify explicit dates in a defined calendar. Thus, in case we use the Gregorian calendar, our time instances and time periods must have a year, and this is either a leap year or not. Thus, an extra attribute isLeapYear would be redundant.

The problem is that simulation systems normally refer to "typical" years with 365 days, and up to now I do not know how to define a special calendar for typical years. In our software, we use a very dirty trick: We use (in the Gregorian calendar) a non leap year in the future to indicate a typical year.

silviacoccolo commented
silviacoccolo commented

Dear all, following the proposition of Romain, shall we have a SkyPe next week to discuss the concrete case? Best,
Silvia

mlauster commented
JoachimBenner commented

Because there are no further comments since a couple of weeks, I finalized the development of the Energy ADE version 0.9.0. In comparison with the last proposal EnergyADE_0_9_0_V2.zip the following changes have been made:

  • Renaming of all abstract classes according to the GML 3.2 style (e.g. _EnergySystem --> AbstractEnergySystem)
  • Renaming of all Enumeraion items and CodeList values (as far as they are integrated into the UML-model) to start with a small letter
  • Renaming of attribute refurbishmentMeasureOnBuilding in _AbstractBuilding into refurbishmentMeasure
  • Renaming of attribute refurbishmentMeasureOnThermalBoundary in ThermalBoundary into refurbishmentMeasure
  • Change of class EnergyConversionSystem into an abstract class AbstractEnergyConversionSystem
  • Integration of a new feature type GenericConversionSystem derived from AbstractEnergyConversionSystem
  • Renaming of Enumeration EnergyCarrierValue into EnergyCarrierTypeValue
  • Renaming of attribute energyCarrier in EnergyFlow into energyCarrierType
  • Renaming of attribute installedNominalPower in AbstractEnergyConversionSystem into installedPower, with type Measure
  • Elimination of attribute serialNumber in AbstractEnergySystem
  • Renaming of class Emitter into EmitterSystem
  • Elimination of attribute unitNumber in EmitterSystem
  • Renaming of attribute condensation in Boiler into hasCondensation
  • Renaming of attribute heatRecovery in MechanicalVentilation into hasHeatRecovery

The UML-Model is attached. All other documents, including a sample file can be found in the CityGML-Wiki

EnergyADE_0_9_0.zip

mlauster commented

Thanks a lot for that update, @JoachimBenner, we are looking forward to the new version!

silviacoccolo commented

Dear Joachim, thank you very much!