Forward translation of schedule fixed interval should use E+ Schedule:File (Bugzilla #417)

[axelstudios]

On 2011-12-06 11:46:08, @macumber wrote:

Otherwise schedules can get so large that E+ cannot run

On 2012-01-13 15:22:02, @DavidGoldwasser wrote:

Updated out of date Milestone Targer

On 2013-01-10 11:36:09, @DavidGoldwasser wrote:

<batch comment: added this to Pivotal Epic, https://www.pivotaltracker.com/epic/show/458473>

Keywords: ForwardTranslation, Invalid?

[DavidGoldwasser]

@macumber maybe not valid, I'll let you decide since we talked about this kind of schedule last week.

[macumber]

I believe the issue with schedules too long to run in E+ was fixed in E+ but I would want to verify. @Myoldmopar do you know of any limit on the size of Schedule:Compact objects?

If the issue is fixed in E+ we should just make a feature request to support Schedule:File and close this bug

[Myoldmopar]

It's an extensible object, so shouldn't be any hard limit, though the idd is currently capped at 4500 fields. Of course, it becomes burdensome as it grows larger, so Schedule:File is much better when you are entering, for example, measured data.

[macumber]

Hmm ok, we we are using (abusing) it for hourly schedules so this might still be an issue. Right now we are using this for daylighting schedules and compressing similar hours together (which helps at night) but this might still bite us for other types of timeseries schedules.

[macumber]

For the record, the reason we do not just simply wrap this object or create it on translation is the additional problems of tracking external file references. I think the safest thing to do would be for the ForwardTranslator to write out a CSV file in the directory which that job runs in, then set an absolute path to it in the IDF. Since we have removed the use case of jobs within a single workflow running on different computers this should work.

@nllong @kbenne any thoughts?

[macumber]

Just to be clear I think we should start off by writing Schedule:File only, we don't need to wrap the object in OS (that would require all the file tracking nonsense). If we want to do reverse translation we could import schedules from Schedule:File to OS:ScheduleFixedInterval

EDIT No longer the case, now that Schedule:File is added to OpenStudio we will translate Schedule:File directly from IDF to OSM

[shorowit]

I really dislike this proposal. Now that OpenStudio users can specify a ScheduleFile object, they should only get an E+ Schedule:File when they specifically request it. If a user instead specifies a ScheduleFixedInterval object, they should get an E+ Schedule:Compact object. I intentionally use ScheduleFixedInterval in OpenStudio on occasion to avoid the E+ Schedule;File. I don't want OpenStudio to make choices for me that I can make for myself.

The only reason I could see deviating from this behavior would be if the E+ Schedule:Compact can't support a given ScheduleFixedInterval object (e.g., due to length).

[macumber]

We could possibly add a new field that controls forward translation?

[shorowit]

That would be fine. I assume FT should default to current behavior for backwards compatibility.

Would another option be to create a method in OpenStudio::Timeseries that can create a CSV file, and then the user can easily create a Schedule:File from it? Or something along those lines.

[macumber]

Yeah, I think there should be something like a CSVFile that can have multiple timeseries in it, both read and write ability. The new thing that makes this possible is the ability of the model to get the OSW file directories to save CSV to.

[joseph-robertson]

Notes:

• i think its pretty straighforward (one new field to the schedulefixed interval object, translate to csv yes/no) but some of the new stuff about finding the model's working directory is a bit odd
• I think "Translate to Schedule File" defaults to false
• version translator will have to insert that field
• i dont think we can translate schedule variable interval to csv so let's skip for now

[macumber]

Let me know when you get started, I can help with a CSVFile class for reading and writing CSV if that helps.