Where should we add the meteo file information to the nmls?

[hcorson-dosch-usgs]

Somewhere along the line we'll need to include the meteo file information in the nml.

We could do that in lake-temperature-model-prep, though that workflow is already set up for NLDAS

Or we could add that information to the nmls in this repo, using the lake-cell xwalk we are creating in our targets sub-pipeline of lake-temperature-model-prep. We'd need to bring that to Caldera somehow - See #4

[jordansread]

I'd suggest writing the meteo_fl value to the .nml file right at runtime for GLM, and fill ahead of time with something that will definitely thrown an error if we try to model with it, such as "NULL". Or leave the meteo_flout of the nml list.

Reason being, the nml (file) or the nml list (object) will be tracked in targets and will contain a value for the meteo file location (unless we remove this field in the list). This may provide false confidence that changes in the meteo file's contents itself would trigger a rebuild if it changes, which it won't because only changes to the file name would cause a rebuild of the model run.

Something like this recipe could work:

run_{model_info_here} <- function(nml_template, nml_list, meteo_fl, out_fl){
# set up model dir/nml
# run model
# deal with results
}

update

I think you've already considered this issue with the meteo_fl contents in mega-issue #1

Bring in Alison's approach of mapping over the created meteo xwalk, so that we can track which models need to be run if a given meteo file is updated. The meteo data is pulled in the execution function I'm not 100% certain that it makes sense to include this approach -- I feel like I will need to get into the code to see if this make sense. And I think it depends on how we choose to set up branching and how/whether we're trying to parallelize this workflow.

[hcorson-dosch-usgs]

@jread-usgs - Okay I'll plan on writing at run-time then, and also implementing Alison's approach. @lindsayplatt I think that means we'll need to export the lake_cell_xwalk_df target from lake-temp-model-prep as a .csv, so that I can pull it in to this repo and use it for both branching and setting the meteo file names

[hcorson-dosch-usgs]

Closing this issue, since it was resolved in #6 - we're using a model configuration target to track the names and hashes of the input meteo data, setting the meteo_fl value to NULL when customizing the nml template, and then writing the meteo data to simulation-specific directories and specifying the name of the meteo_fl in the nml when each model is executed.