feat: added multiplier to type limits

[TfedUD]

This PR adds an additional type limit to the def schedule_type_limit_to_inp to allow for MULTIPLIER type limits to pass

[chriswmackey]

Hey @TfedUD ,

I support making this change but it's not implemented correctly. Honeybee-energy ScheduleTypeLimits are objects that have their own properties. They are different from ScheduleTypeLimits in DOE-2 where it's really just a bit of text that denotes what the type is.

So, instead of:

elif type_limit  == 'Multiplier'

it should be:

elif type_limit.display_name  == 'Multiplier'

See here in the honeybee-energy docs for more guidance:
https://www.ladybug.tools/honeybee-energy/docs/honeybee_energy.schedule.typelimit.html

[TfedUD]

Hi @chriswmackey I didn't think type_limit had MULTIPLIER as an option.
see typelimit.py here
Also multiplier doesn't work with type_limit component

Would the class ScheduleTypeLimit(object) in typelimit.py also need modification to allow for MULTIPLIER to work?
Currently im using the schedule_day_to_inp having modified the code on my install to match the PR, but I can just as easily have the component take a HB Type Limit instead of a text string

Should the changes be your aforementioned, as well as adding multiplier to ScheduleTypeLimit?

[chriswmackey]

Hey @TfedUD ,

EnergyPlus does not have a unit_type for multiplier since multipliers are not really something that you schedule in E+, though you can kinda do this with the EMS. If you wanted to construct a type limit for something like a multiplier in E+, the type limit would probably have discrete_ set to True, and the unit_type would probably be something like Dimensionless, Control or Mode. But that's why I was thinking that maybe we should not rely on the unit_type to tell us whether the type should be translated to eQuest as Multiplier. Maybe we should just see if the user chose the name Multiplier when they created the type and, if so, we translate it to the eQuest Multiplier type:

[TfedUD]

Sorry about how late this edit was.