-1 is valid for model_id for workflows

[robkooper]

-1 is used for those models that have no entry in the database but still have all the required pieces, thus -1 is a valid value when writing to the workflow table.

[dlebauer]

@robkooper

What scenario are you describing?

• A workflow with a model that exists, and has wrappers in PEcAn, but is not in the database? Why not just require a record for the model in the database?
• A workflow that doesn't use a model?
• other?

Some options:

• require a record in the models table for a specific model
• create an arbitrary "dummy" row for an "unidentified" model
• create a record in the models table with id = -1
• create an arbitrary "dummy" row for a workflow that does not use a model

[mdietze]

I know that Rob was using -1 in the system tests on read.settings

[robkooper]

If you specify a model with no id, but with a type, and binary it is a valid way of describing the model for PEcAn to operate, however the model might not exist in the database (for example when you want to use your own version of ED). At this point I can not find a model_id and will use -1 to indicate the model is not in the database.

[dlebauer]

@robkooper would it be reasonable to either

• use "NULL" instead of -1 - that is the way we handle foreign keys that do not have associated records.
• enter a new record in the models table?

In the case you mention, we would at least have a model name, server, binary, and modeltype.

[robkooper]

I don't want to add throw away models to the system because a user is experimenting with a new model. Once it is official for others to use it should be added to the database.

I'll try and see what happens with the NULL.

[dlebauer]

experimenting with a new model.

Shouldn't write = FALSE for an experimental run? Is there a case where provenance would be useful for a workflow that includes an arbitrary model?

Once it is official for others to use it should be added to the database.

I think that 'official' is vague. Neither commits nor tags have any requirement that the version be 'official' or intended for general use, and interesting research can be done on versions that are not 'official' releases (e.g. how model skill changes with each commit, which overlaps with benchmarking / integration testing of models).

[dlebauer]

@robkooper I still don't see where it would be useful to allow modeltype_id to equal -1 (but not, say, -2), or why this would be preferable to max(id) + 1, we do have a billion rows on this table per server after all .... and the row can be deleted at some point if the user wants to. What if user 1 creates a model with modeltype_id = -1 and then user 2 wants to experiment with a model?

So, can we close this issue? Or should we change the value constraints?

[mdietze]

@dlebauer -1 is preferable to N+1 because as soon as someone adds a new modeltype we'd have to renumber all past records. I don't know if @robkooper had a chance to play with whether NULL works or not but I'm in favor of changing the constraint.