I created the init_state() pattern in order to give us more control over object creation order and to simplify and clean up unit tests. For a while, things were going swimmingly with leaf-objects like Schedule, Material, Curve, and FluidProperties "following the rules".
However, in my recent attempt to break up a giant coil-API PR into bite-sized pieces, I had the idea that one of the first things I should do was put the coils into this pattern and get all of the object-ordering diffs out of the way. After all, coils only reference Schedule and Curve objects and these were already created? What could possibly go wrong?
A better question, or at least one that would not take as long to answer, would have been what would go right? In short, this seemingly small change broke something in every little corner of EnergyPlus. From EMS (for reasons yet unknown) to unit tests expecting certain meters to be in hard coded positions (bad, bad unit tests!!) but the thing that was most disturbing is that tests began failing because of malformed objects. How's this, you ask? Well, it turns out that it's okay for an IDF file or test snippet to have a malformed HeatingCoil or two if those objects are never fully read. They are either not really part of the model, just cruft left over in the IDF file from a previous model or they are in a unit test where all that is needed is for their presence to be validated. My question is whether this is a bug or a feature. Are interface developers relying on this behavior to avoid cleaning up IDF files? Note, there are some legitimate reasons for having unused objects in IDF files (e.g., you're testing ECMs). But I don't really see too many legitimate for having malformed unused objects in IDF files. And in case you are wondering how a malformed object gets into an IDF file to begin with, well it starts out as a well-formed object but then one of the objects it references is renamed or deleted and so the object cannot fully load because of "ItemNotFound" errors.
TL;DR I am wondering if it is worthwhile going down this path or I should turn around quickly because who knows what else I might find.
I created the
init_state()pattern in order to give us more control over object creation order and to simplify and clean up unit tests. For a while, things were going swimmingly with leaf-objects likeSchedule,Material,Curve, andFluidProperties"following the rules".However, in my recent attempt to break up a giant coil-API PR into bite-sized pieces, I had the idea that one of the first things I should do was put the coils into this pattern and get all of the object-ordering diffs out of the way. After all, coils only reference
ScheduleandCurveobjects and these were already created? What could possibly go wrong?A better question, or at least one that would not take as long to answer, would have been what would go right? In short, this seemingly small change broke something in every little corner of EnergyPlus. From EMS (for reasons yet unknown) to unit tests expecting certain meters to be in hard coded positions (bad, bad unit tests!!) but the thing that was most disturbing is that tests began failing because of malformed objects. How's this, you ask? Well, it turns out that it's okay for an IDF file or test snippet to have a malformed
HeatingCoilor two if those objects are never fully read. They are either not really part of the model, just cruft left over in the IDF file from a previous model or they are in a unit test where all that is needed is for their presence to be validated. My question is whether this is a bug or a feature. Are interface developers relying on this behavior to avoid cleaning up IDF files? Note, there are some legitimate reasons for having unused objects in IDF files (e.g., you're testing ECMs). But I don't really see too many legitimate for having malformed unused objects in IDF files. And in case you are wondering how a malformed object gets into an IDF file to begin with, well it starts out as a well-formed object but then one of the objects it references is renamed or deleted and so the object cannot fully load because of "ItemNotFound" errors.TL;DR I am wondering if it is worthwhile going down this path or I should turn around quickly because who knows what else I might find.