LifeCycleCost:UsePriceEscalation bad E+ IDD

[macumber]

In ProposedEnergy+.idd for LifeCycleCost:UsePriceEscalation

A1, \field LCC Price Escalation Name

should be

A1, \field Name

prevents the .name method from working, reported by @DavidGoldwasser

[joseph-robertson]

This fix should be straightforward.

However, I'm confused why LifeCycleCostUsePriceEscalation is in the public API (it's not swigged and therefore its ctor is undefined). Should its ctor be available? If so, how would we modify ft of LifeCycleCostParameters to use/write these custom LifeCycleCostUsePriceEscalation objects?

Perhaps we just make the ctor private and call it good?

@jmarrec @kbenne

[jmarrec]

I'm guessing that initially they were implemented in model API, then someone (Dan apparently) realized they could be created from LifeCycleCostParameters. So they weren't SWIGGed but left in place (in case we changed our minds later probably)...

https://github.com/NREL/OpenStudio/blob/2fe43e38d04570310be30725a8c6d175853fa1fe/src/energyplus/ForwardTranslator.cpp#L2196

I think we could remove the model class, but it doesn't hurt right now.

Confirmed that this is still a "problem" today, so changing ProposedE+.idd will fix this.

idf_esc = OpenStudio::IdfObject.new("LifeCycleCost:UsePriceEscalation")
idf_esc.setName("TESSSSST").empty?
=> true

If we wanted to allow people to overwrite these and provide their own, then just SWIG it, then in the FowardTranslateLifeCycleCostParameters

• If use NIST escalation (useNISTFuelEscalationRates == true): don't translate the model ones, use the NIST ones
• If not, then loop on available fuels: for each
  • If you find an OS:LifeCycleCost:UsePriceEscalation with a Resource == : translate that one
  • Otherwise do like right now, infer by calling the helper makeUsePriceEscalation

If we go that route, I'd actually make the LifeCycleCostUsePriceEscalation CTOR private, and rely on a static factory method LifeCycleCostUsePriceEscalation::getLifeCycleCostUsePriceEscalation(const std::string& fuelType) or something like that to prevent user from creating two objects with the same "Resources" fuel

[joseph-robertson]

Decided to address only the problem in this issue, and nothing more.

@jmarrec

[jmarrec]

@joseph-robertson that's a good idea I think. Perhaps the other part could be made an enhancement request for a later date addition, or we could just wait to see if someone actually has a use case for bringing it in the model api (my opinion is the latter)