@Myoldmopar I'm having a hard time making heads or tails of the failing CI results here. Are they legitimate or is there something else going on? Maybe we should pull in develop?

@nmerket @shorowit
One test added, welcome to comment!

Multispeed coil capability added in #7271 Pull Request

@mjwitte @rraustad @nmerket The multispeed coil already has reclaimed heat calculation within DXcoils.cc, so I simply added the connection in WaterThermalTanks.cc. One thing looks a little bit confusing is that the Coil:Cooling:DX:TwoSpeed used COIL_DX_MULTISPEED as reclaim source label. So I made them sharing the same label in WaterThermalTanks.cc. They didn't have anything unique in these functions so it worked out well.

The multispeed desuperheater energy and available reclaimed heat were plotted below, the desuperheater coil only heats when cooling coil is working . The desuperheater setpoint is 60C never achieved in these plotted points so the source mass flow rate and desuperheater energy should be of the same shape as available reclaimed heat. Since this is a DX cooling coil, the impact of reclaiming heat is neglected (no reclaimed heat data return back to coil calculation).

I surprisingly found when I tried to use a model with Kiva to install desuperheater, the initial model (without desuperheater) crashed with runperiod starting from 05/01, but worked well with runperiod starting from 01/01. It failed even in latest develop branch with an error shown below. I think this might be a bug in kiva? If you want the model starting 05/01, click here to GoogleDrive

For desuperheaters, I think COIL_DX_MULTISPEED is specific to Coil:Cooling:DX:TwoSpeed so this is (sort of) OK as far as I can tell. If anyone ever adds Coil:Cooling:DX:MultiSpeed as a source for desuperheaters, and does not catch/correct this subtlety (if it needs correction to work properly), then this may be a problem.

In your test file, what is the reclaim efficiency for the desuperheater? It looks to be about 10% in your plot. I ask because I thought 30% was the typical choice. And you are plotting Cooling Coil Electric Energy, not Cooling Coil Total Cooling Energy (and 10% is higher than it would be when comparing to Cooling Energy).

Coil:WaterHeating:Desuperheater,
  0.3,             !- Rated Heat Reclaim Recovery Efficiency

Oh, you are comparing to Electric + Cooling Energy. So why does this look like about 10%? Is reclaim efficiency = 0.1?

Oh, you are comparing to Electric + Cooling Energy. So why does this look like about 10%? Is reclaim efficiency = 0.1?

Hi, @rraustad , I set the reclaim efficiency as 0.25 in my test file. I am quite sure it might be caused by this line 9095.
In the test file, the ratio reclaimed divided by total available is about 0.105469 all the time when desuperheater is available.

There seems to be an internal iteration happens within water thermal tank simulation (which makes the subtraction happens more than once per time step, I estimated it happens four times in this model, see below the calculation for this assumed issue:)

I also ran an existing desuperheater model (Coil:Cooling:DX:SingleSpeed) with E+ 9.1.0, it also gave a very similar result:

So I would think it's an old bug need to be fixed. I am not sure if it should be done in this PR?

If you want to check these two models:
SingleSpeedCoolingCoil
MultiSpeedCoolingCoil

And I ran with Tampa 722110 weather.

For desuperheaters, I think COIL_DX_MULTISPEED is specific to Coil:Cooling:DX:TwoSpeed so this is (sort of) OK as far as I can tell. If anyone ever adds Coil:Cooling:DX:MultiSpeed as a source for desuperheaters, and does not catch/correct this subtlety (if it needs correction to work properly), then this may be a problem.

I would also think this might be fine with either TwoSpeed or MultiSpeed or together. I searched within the scope of water thermal tanks functions, I am pretty sure they followed exactly the same workflow and called the same functions in all those ifs. And awkwardly the two speed coil has taken up the name of multi-speed, so I simply combined them. 😝

@yzhou601, this is not on you (but we like to know what is wrong). You have done more than expected. Just identify what is wrong and make a new issue. We can fix it there.

The reclaim efficiency of 25% is applied to the available coil heat rejection (including impact of PLR) so seeing heat reclaim of 0.1 is OK if PLR = 0.4. So desuperheater heat reclaim divided by coil PLR will always = 25%.

Thanks @rraustad!
@rraustad @nmerket @mjwitte @Myoldmopar Tell me if there's anything else needs to change in this PR.

@Myoldmopar Have your comments been resolved? OK to merge?

Hi, @rraustad @mjwitte , some updates of this PR.

Thanks to @rraustad 's array approach, the results run locally with gshp cooling coil + desuperheater + stratified tank now track energy as intended:

Array is allocated by the number of water heating desuperheater objects, so that it could directly use the desuperheater index as pointer. The use of "DesuperheaterReclaimedHeat" now changed to "WaterHeatingDesuperheaterReclaimedHeat" to be more specific.

@rraustad @mjwitte Something weird here, I ran the same test file here with released E+ 9.2.0, the coil source side energy is no longer balanced as shown in the table. I revisited the codes where I made those changes, they are, however, kept untouched. The energy balance between coil source side and desuperheater reclaimed heat was verified when tested on July 17 and retested by @mjwitte on July 31, I didn't know if there's any change made later at its top broke things here.
The 9.2.0 released version results, if looking on the tank side, the reclaimed heat, though changed, is still reasonable compared with previous results. But the (coil cooling energy + coil electric energy - reclaimed heat) is not equal to coil source energy.
Appreciate it very much if you can help take a look at this. Please let me know if you have any clue.

test file
epw: Tampa 722110

@yzhou601 Looking at my test files from then and re-rerunning those now, I get similar results (then and now). I'd suggest building a version with the commit where you added the desuperheater array approach - and reconfirm that it balances. Then use git bisect between that commit and the final v9.2.0 commit to find when the results changed to be imbalanced.

@mjwitte Thanks very much for revisiting these tests, Mike. I followed your suggestion, and just recalled some detail that caused this confusion.

When I was testing and summarizing that table in previous comment, I found in WaterToAirHeatPump.cc, Qsource is initially calculated by these lines. It's adjusted by QSource_fullload (defined previously as sum of Winput and QLoadTotal) applying PartLoadRatio while Winput(Later is taken for reporting Cooling coil electric energy) is taking RuntimeFrac. So it's the difference between PartLoadRatio and RuntimeFrac that caused:
Cooling Coil Total Cooling Energy + Cooling Coil Electric Energy != Cooling Coil Source Side Heat Transfer Energy

So that means this issue is not just for desuperheater coupled with gshp, but all gshp systems with this coil type( not sure if other coil follows the same way). To separate this impact, I did a build with RTF forced to be equal to PLR, that's why the previous table showed perfect energy balance. And I rebuilt the current master branch and tracked a few hours, the energy was balanced excluding the RTF and PLR difference.

So, do you think this is a defect of calculating Qsource (should it directly sum those adjusted Winput and QLoadTotal again instead of applying PLR)?

Once I talked with @rraustad for this issue, but didn't have any conclusion at that point for Qsource since we only focused on things related to desuperheater.

That makes perfect sense. The thermal energy is typically proportional to PLR while electrical energy is proportional to RTF, or at least that's how E+ has always handled thermal vs electrical for air systems since the compressor energy does not impact the air stream in cooling mode. For water coils E+ currently uses:

QSource_fullload = QLoadTotal + Winput; (total energy available for thermal transfer)
QSource = QSource_fullload * PartLoadRatio; (actual thermal energy)
SetupOutputVariable("Cooling Coil Source Side Heat Transfer Rate", OutputProcessor::Unit::W,
                                    SimpleWatertoAirHP(HPNum).QSource,  "System", "Average",
                                    SimpleWatertoAirHP(HPNum).Name);

But this source side energy transfer is missing the additional electrical energy due to startup losses. Since RTF = PLR / PLF, then the actual thermal energy should include the additional electrical energy required for startup.

    These lines seem correct but where do the startup electrical losses go?
    QLoadTotal *= PartLoadRatio;
    QSensible *= PartLoadRatio;
    Winput *= RuntimeFrac; (includes startup losses)

     so this line:
    QSource = QSource_fullload * PartLoadRatio;
     should be changed (if I am thinking through this clearly) to:
    QSource = QLoadTotal + Winput;

and then Cooling Coil Electric Energy + Cooling Coil Total Cooling Energy will equal Cooling Coil Source Side Heat Transfer Energy.

At least that is the idea to correct these differences. I think this same mentality should apply to air systems in heating mode.

That makes perfect sense. The thermal energy is typically proportional to PLR while electrical energy is proportional to RTF, or at least that's how E+ has always handled thermal vs electrical for air systems since the compressor energy does not impact the air stream in cooling mode. For water coils E+ currently uses:

QSource_fullload = QLoadTotal + Winput; (total energy available for thermal transfer)
QSource = QSource_fullload * PartLoadRatio; (actual thermal energy)
SetupOutputVariable("Cooling Coil Source Side Heat Transfer Rate", OutputProcessor::Unit::W,
                                    SimpleWatertoAirHP(HPNum).QSource,  "System", "Average",
                                    SimpleWatertoAirHP(HPNum).Name);

But this source side energy transfer is missing the additional electrical energy due to startup losses. Since RTF = PLR / PLF, then the actual thermal energy should include the additional electrical energy required for startup (or QSource *= PLF, where PLF is calculated in the parent and not available here).

    These lines seem correct but where do the startup electrical losses go?
    QLoadTotal *= PartLoadRatio;
    QSensible *= PartLoadRatio;
    Winput *= RuntimeFrac; (includes startup losses)

     so this line:
    QSource = QSource_fullload * PartLoadRatio;
     should be changed (if I am thinking through this clearly) to:
    QSource = QLoadTotal + Winput;

and then Cooling Coil Electric Energy + Cooling Coil Total Cooling Energy will equal Cooling Coil Source Side Heat Transfer Energy.

At least that is the idea to correct these differences. I think this same mentality should apply to air systems in heating mode.

Thanks Richard, if it's fair enough I can open up a new PR to correct this along with the remaining reclaimed heat issue #7407 .