Convert htFluxWaterFromCoil GD into EquationalModel

[balacij]

Relies on #2444

Reorders 1 area of the references slightly. I'm not entirely sure why it does this.

Leaving it as a draft PR.

[balacij]

Going through other GDs, it seems this same issue where it just results in a reordering of the references occurs a few times. However, I haven't (yet?) seen this occur with IMs or TMs.

[balacij]

Just found a TM with the same issue: TM: mcShrStrgth of SSP.

EDIT: And another, TM: effStress of SSP.

[JacquesCarette]

Re-ordering of the references is not a huge deal. Although they ought to be stable, as I'm pretty sure they are sorted. So something else is also going on.

Having the label name change completely is a very different issue. We need to understand why this arises.

[balacij]

@JacquesCarette I think I've figured it out now. Thank you for your hint, I did not know they were sorted!

I was looking around examples when I spotted GlassBR's DD: gTF. It looks like this one isn't sorted too. Most RefBy's have reverse alphabetical sorted lists of references, but this one was seemingly not reversed, it's in standard order. However, taking a closer look at their definitions I realized that the UID of calOfCapacity is actually derived from it's QDefinition which defines lRe so it's UID ends up as lResistance while the UID of dimlessLoad is just dimlessLoad. So, since we sort by UIDs, this one is technically ordered (by UID) despite the rendered labels not appearing to be ordered.

So then I take a closer look at my change. With the RelationConcept, the UID it was sorting against was manually set to htFluxWaterFromCoilRC but when I changed it to an EquationalModel (which bases it's UID on the thing that it's QDefinition defines) based on htFluxC, I ultimately changed the UID to htFluxC. Meanwhile, the UID of htFluxPCMFromWaterQD (to which it's compared against in the references list) has UID htFluxP which is why in the end, it gets sorted as per the code intends but with an unintended side effect.

Finally, if we're okay with changing the UIDs of htFluxP and htFluxC slightly, then we can revert our changes to stable. Perhaps, htFluxP (htFluxPCMFromWater) to htFluxPW, and htFluxC (htFluxWaterFromCoil) to htFluxWC. e.g., we would be changing the unitals as follows:

htFluxC = uc' "htFluxWC"
  (nounPhraseSP "heat flux into the water from the coil")
  "the rate of heat energy transfer into the water from the coil per unit time"
  (sub (eqSymb htFlux) lCoil) UT.thermalFlux

htFluxP = uc' "htFluxPW" (nounPhraseSP "heat flux into the PCM from water")
  ("the rate of heat energy transfer into the phase" ++
  "change material from the water per unit time")
  (sub (eqSymb htFlux) lPCM) UT.thermalFlux

(and we can change the actual Haskell variables names too if we wanted to)

Disclaimer: I don't know if this is the best solution, but I do think that the name change would ever so slightly better follow the definition of the unitals.

[balacij]

While we decide the correct course of action, I posted the hacky (?) fix in 6aab6ed for the purpose of this review's proof of concept.

[balacij]

Recalling a previous discussion we had actually, you mentioned that we should create a new UID for the QDefinition, perhaps that's the better solution? If so, would we want to have it, for example, always append "QD" to the end of the UID of the thing it defines?

[ However, in this case, it would still be a problem since the appended "QD" would not really change the ordering. ]

[JacquesCarette]

Sorting by UID is horrible. We shouldn't do that. I'll open an issue.

Hacking UIDs to artificially fix ordering issues it not really a fix either. If the UID changes for good reasons, then let's allow the re-sorting (at least until #2468 is fixed).

What I was more concerned with, is that the user-visible label seemed to change. And I wonder how/why that happened.

[balacij]

Sounds good, I'll just revert my last commit then, and then we can wait until #2468 is fixed then. In that case, this issue won't be a blocker for some other ones too (which is great!).

Thank you!