Issue1436 add pvt model

[LoneMeertens]

Fixes #1436 .

This PR implements a validated dynamic PVT collector model based on EN12975 and includes electrical coupling, as described in issue #1436

Two large files were added to support validation:

• IDEAS/Resources/Data/Fluid/PvtCollectors/Validation/PVT2/PVT2_Austria_wheaterData.mos
• IDEAS/Resources/Data/Fluid/PvtCollectors/Validation/PVT2/PVT2_measurements.txt
  These contain 5-second interval data. They were uploaded using Git LFS to bypass GitHub's file size limit. However, I'm concerned about the long-term relevance and maintainability of including such large files in the main repository. Suggestions on how to best handle this (e.g., external hosting, downsampling, separate data repo) are welcome.

@jelgerjansen: If you have comments about structure or integration with the broader library, please let me know.

[lucasverleyen]

@LoneMeertens thanks for creating this new model, it's a nice development! :-)
Regarding the structure: This looks fine to me. I checked, and IDEAS does not apply a very consistent order of the Data, Examples, Validation, BaseClasses and Types packages. Neither does the Buildings library. However, the order you apply seems to be the most recurring one.

Regarding the large files: if the model is developed and validated within IDEAS, I think it is best to add all original data. Moreover, the files are static. Just make sure that you only add the data that you use for validation.

I'll have a first look at your implementation now, I am curious ;-)

[lucasverleyen]

@LoneMeertens I had a quick view at your models, looking great :-) I have added some (first) suggestions.

[lucasverleyen]

What is the meaning of 1 and 2? I would keep the naming descriptive, e.g. WithRearInsulation and WithoutRearInsulation.

[LoneMeertens]

I used 'PVT1' and 'PVT2' in the paper referenced, as it seemed the most straightforward and user-friendly way to help readers quickly connect the two datasets. However, since most users likely won’t make the effort to look up the paper, it seems better to use 'WithRearInsulation' and 'WithoutRearInsulation' instead, thanks for the suggestion!

[jelgerjansen]

@LoneMeertens I did a review of all models except those in the Validation package. I propose you first have a look at my comments, and then use that feedback for the Validation package as well.

[jelgerjansen]

• The model could also be used in the solar thermal collector model. Maybe we should have a thought on how to use this BaseClass model for both PVT and STC in the future (could be discussion in the Modelica Working Group)
• The model is called EN12975, but the description only mentions ISO 9806:2013. What is the link with EN12975?

[LoneMeertens]

Good point! The model originally extended from EN12975HeatLoss (SolarCollectors package), which implements the steady-state method from the now-outdated EN 12975 standard. However, the logic in this model follows the ISO 9806:2013 quasi-dynamic method, which has replaced EN 12975-2 as the current international standard. To reflect this, I’ve renamed the model to ISO9806QuasiDynamicHeatLoss.

That said, this does raise a broader question: since ISO 9806 has fully replaced EN 12975, should we also consider renaming the STC model to avoid confusion and align all naming with the current standard?

[LoneMeertens]

@jelgerjansen Thank you for the elaborate review, it was very useful to help create a more compact and clear structure within the PVTCollector package. I’ve now implemented all the suggested changes across the models, including those in the Validation package. Here’s a summary of the main structural changes:

1. Heat loss model simplification: I’ve minimized the number of new (heat loss) blocks by extending directly from SolarCollectors models. The ISO9806QuasiDynamicHeatLoss block now extends from EN12975HeatLoss, redefines a1 and a2 to c1 and c2, and includes the additional coefficients. This removed the need for an intermediate partial model.
2. Electrical output model: A separate block (ElectricalPVT) was added to calculate electrical output explicitly.
3. Direct extension from base collector: The PVTQuasiDynamicCollector model now extends directly from PartialSolarCollector and integrates the following:
   - Electrical generation via ElectricalPVT
   - Quasi-dynamic thermal losses via ISO9806QuasiDynamicHeatLoss
   - Solar (thermal) gain via EN12975SolarGain, with the necessary interconnections.
4. Generic datasheets: Added representative datasheet records for different PVT types, to be used when no brand-specific data is available.
5. Validation models: All changes mentioned above have been applied in the Validation package as well, reducing model redundancy.
6. Documentation: Extended documentation and references are now included with the models.

Follow-up points:

1. Naming – PVT1 and PVT2: These names are consistent with the reference paper, which improves traceability. However, if preferred, I can align them with the datasheet naming convention for consistency.
2. EN12975 → ISO9806: I’ve renamed the models to reflect the current ISO9806 standard. Since ISO9806 supersedes EN12975 and includes both steady-state and quasi-dynamic approaches, it might make sense to adapt the naming in the STC package as well. Let me know your thoughts on applying this more broadly.
3. Large validation data files: The PVT2 validation relies on high-resolution data (5 sec, 58 days). These files are quite large; how would you prefer we handle their storage and access (e.g. external repository, compressed archive, etc.)?

[LoneMeertens]

@jelgerjansen @lucasverleyen Do you still have time to have a look at this PR before the IDEAS release?

Follow-up points (taken from above and extended):

1. Naming – PVT1 and PVT2: These names are consistent with the reference paper, which improves traceability. However, if preferred, I can align them with the datasheet naming convention for consistency.
2. EN12975 → ISO9806: I’ve renamed the models to reflect the current ISO9806 standard. Since ISO9806 supersedes EN12975 and includes both steady-state and quasi-dynamic approaches, it might make sense to adapt the naming in the STC package as well. Let me know your thoughts on applying this more broadly.
3. Large validation data files: The PVT2 validation relies on high-resolution data (5 sec, 58 days). These files are quite large; how would you prefer we handle their storage and access (e.g. external repository, compressed archive, etc.)?
4. Should we also include the .mos and .py scripts used to derive the values from the paper/in the documentation, to ensure full transparency in the validation process? Or do you consider the models and data alone to be sufficient?

Let me know your thoughts.

[jelgerjansen]

@jelgerjansen @lucasverleyen Do you still have time to have a look at this PR before the IDEAS release?

Follow-up points (taken from above and extended):

1. Naming – PVT1 and PVT2: These names are consistent with the reference paper, which improves traceability. However, if preferred, I can align them with the datasheet naming convention for consistency.
2. EN12975 → ISO9806: I’ve renamed the models to reflect the current ISO9806 standard. Since ISO9806 supersedes EN12975 and includes both steady-state and quasi-dynamic approaches, it might make sense to adapt the naming in the STC package as well. Let me know your thoughts on applying this more broadly.
3. Large validation data files: The PVT2 validation relies on high-resolution data (5 sec, 58 days). These files are quite large; how would you prefer we handle their storage and access (e.g. external repository, compressed archive, etc.)?
4. Should we also include the .mos and .py scripts used to derive the values from the paper/in the documentation, to ensure full transparency in the validation process? Or do you consider the models and data alone to be sufficient?

Let me know your thoughts.

@LoneMeertens

1. I would change the component name to something more meaningful and refer to PVT1/2 in the documentation of these models.
2. The STC model was based on EN12975, so I wouldn't change anything now. Only if the models are revised as well (which makes sense!). To be discussed in an upcoming MWG meeting.
3. Are you using all data, or only a fraction of it? It would make sense to add it to the library to keep everything together. Maybe we can check with IT if there is a good solution? If this is not possible, maybe direct to the raw data (and add the conversion script you used to have a Modelica-proof file). Another solution is to store it on OneDrive and share this link
4. No need to add all files, clearly refer to the paper. The mos files are needed for the unit testing as well, so for that one you could use similar ones as you used for the paper.

[LoneMeertens]

@LoneMeertens

1. I would change the component name to something more meaningful and refer to PVT1/2 in the documentation of these models.
2. The STC model was based on EN12975, so I wouldn't change anything now. Only if the models are revised as well (which makes sense!). To be discussed in an upcoming MWG meeting.
3. Are you using all data, or only a fraction of it? It would make sense to add it to the library to keep everything together. Maybe we can check with IT if there is a good solution? If this is not possible, maybe direct to the raw data (and add the conversion script you used to have a Modelica-proof file). Another solution is to store it on OneDrive and share this link
4. No need to add all files, clearly refer to the paper. The mos files are needed for the unit testing as well, so for that one you could use similar ones as you used for the paper.

@jelgerjansen @lucasverleyen

1. I changed all naming of PVT1 to PVT_UI and PVT2 to PVT_UN to be consistent with the naming of the corresponding records. In the documentation of the validation models, I clearly refer to PVT1 and PVT2 as used in Meertens et al. (2025), so the link to the original naming is preserved.

2. I agree, no changes to the STC model for now. We can revisit this if the models are revised, as discussed in the upcoming MWG meeting.

3. I’m using all the data from the file (the full 58 days). If Git LFS doesn’t have any major disadvantages beyond the additional time needed to clone the repository, it seems like the most straightforward solution to keep everything together.

4. Ok, perfect.