Baseline model output

[mmuellerstoffels]

@jbvandermeer Have you defined baseline model output yet? That is, which files are generated for the baseline model run. Where are they stored?

Since we will be running models multiple times (with different configurations) need to further subdivide the OutputData folder to be able to identify reliably what is what.

Please come up with a suggested way of naming subfolders and files to ensure we can keep them straight (I assume you already have somewhat of a system for you Matlab-based model?)

[mmuellerstoffels]

@jbvandermeer Have you come up with a naming convention? I need this for developing routines for data retrieval and assessment in the optimization package.

[jbvandermeer]

They will be stored in ProjectFolder/OutputData/Runx/ where 'x' is the run number. The files will be net cdf. File names will be the name of SystemOperations variables with 'Runx' afterwards. For example, 'wtgPchRun0.nc'. I will also add some component specific files, which will have the component name followed by the attribute, for example 'gen0PRun0.nc'

[mmuellerstoffels]

So, is there a xml file that connects run numbers to the parameters, e.g. ESS P and ESS E, particular dispatch rules should they have changed, etc.? Or will there be a projectSetup.xml and all the component xml for each run?

[jbvandermeer]

That is a good idea. Right now it is in a csv file which is used as an input to the simulation. But I will create an output xml file as well. It will be in the ProjectFolder/OutputData directory.

[mmuellerstoffels]

Please provide me with the schema for the output xml file/a sample output xml file.

[jbvandermeer]

I will do that later today when I have my laptop

On Tue, Feb 27, 2018 at 9:15 AM Marc Mueller-Stoffels < notifications@github.com> wrote:

Please provide me with the schema for the output xml file/a sample output xml file.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mmuellerstoffels/GBSTools/issues/61#issuecomment-368911600, or mute the thread https://github.com/notifications/unsubscribe-auth/AdIAMC3TNIkWbIBqBgq-N2qtjVTZDhLVks5tZBwJgaJpZM4SACHE .

--

Jeremy VanderMeer, MSc. Research Engineer Alaska Center for Energy and Power Institute of Northern Engineering University of Alaska Fairbanks

jbvandermeer@alaska.edu mmuellerstoffels@alaska.edu

+1 (907) 888 2632 <javascript:void(0);> (office) +1 (907) 750 2894 <javascript:void(0);> (cell)

[jbvandermeer]

I added componentsUsed.xml to the GBSModel/Resources/Setup directory. It simply lists which components were used in that simulation run. This file, with the projectSetup.xml file, will be saved in the OutputData directory in each project. It should give enough information about how the simulation was run. The information for each component will be in the InputData/Component directory, and the time series data used in the InputData/TimeSeries directory. We could save component and possibly time series data in each run directory, in case it gets changed in the input folder after the simulation is run. This would mean redundant files, but safer against them getting changed afterwards. What do you think?

[mmuellerstoffels]

Thanks for building the xml infrastructure.

Regarding copying input time series into output folders: it would ensure maximum clarity regarding the inputs for a particular simulation. However, this could also quickly balloon data volume with the redundancy you mention. This also points at a greater issue regarding file versioning during input time series generation. Currently, we do not have a means of tracking which version of GBSInputHandler package (and routines therein) a time series file has been created with (creation dates in the file structure are not reliable for this). A clean and 'user proof' fix for this would be quite the effort. Even if we added a variable 'dateCreated', and 'codeReleaseUsed' to the netCDF files, we'd still have to rely on user discipline (just as with not deleting inputs that have actually been used to generate outputs).

So, I think for now, we should carry copies of the the component descriptor files, the dispatch, and all other meta-data, but not the time-series. Better handling of this should be on a the wishlist for future versions of the tool.

[jbvandermeer]

Also, the load time series and the wind power time series converted from the wind speed time series will be saved in the output data. The wind power curve will also be saved, so should be able to back out the wind speeds if desired.

[mmuellerstoffels]

Yes, I was thinking that much of the model input time-series (at the very least the firm demand and wind power available [not necessarily used]) would make it back into the output time series anyhow. I think that will be good for now.