search

cmip6dr / Request

Request specification (which variables for which experiments, etc)
2 stars 0 forks source link

No requests for ssp119? #110

Closed JamesAnstey closed 4 years ago

JamesAnstey commented 4 years ago

When I use the command-line tool to search for priority=1 ssp119 requests,

drq -m _all_ -p 1 -e ssp119 --xls

I find no requests at all. Priorities 2 & 3 are similar. I'm using the latest version, 01.00.31.post3. Is this an error or am I using the tool incorrectly?

martinjuckes commented 4 years ago

Hello @JamesAnstey , it is an unfriendly "feature": the default in the tool is only to provide results for tier=1 experiments, even when a tier=2 experiment is specified. To get the request for ssp119 you need to add -t 2 to the command line.

I'm not sure how best to fix this. I don't like the idea of making defaults depend on argument values (because it could lead to some messy logic), so I think I will try adding a warning, along the lines of:

WARNING: all experiments excluded by default tier=1 filter. Modify experiment list or re-run with -t 2 or 3

JamesAnstey commented 4 years ago

Hi @martinjuckes, thanks for the reply. That's definitely counterintuitive... to code issuing a warning would be helpful.

I don't understand why the tier is even needed when the experiment name is specified - shouldn't the tier only matter when it's necessary to create a list of experiments? i.e. if the user has specified the tier, but not any experiment names. And then the default tier setting would only be relevant if the user has not provided any experiment name(s) or any tier.

martinjuckes commented 4 years ago

Hi James,

There is potential for confusion if the user specifies a MIP name (e.g. scenarioMIP) to indicate a collection of experiments. In this case, it does make sense to allow the list to be filtered by tier. The user could also specify a multiple experiments in the command line, and then use a filter: perhaps not a very common use-case, but certainly a possibility. To separate these out, I would like to go through a more thorough review of the API. In the meantime, I'll add a warning.

JamesAnstey commented 4 years ago

Hi Martin - yes, good point about the MIP name. That's essentially just another collection of experiments, right? (i.e. all experiments defined by that MIP) So I agree in that case it is useful to have a default tier value. But ultimately a tier value and/or a MIP name are just convenient ways to identify collections of experiment names. It seems to me most logical that if a user says that they want a given experiment (identifying it by name) then there should be nothing under the hood that second guesses that choice, since ultimately the buck stops with the experiment name, doesn't it? But I appreciate that if these details are buried in the API it may be nontrivial to adjust. Cheers for adding the warning, that will be helpful.

martinjuckes commented 4 years ago

Hi James, another issue is that I have promised not to change the API. I agree that I agree that this specific change shouldn't hurt anyone, but it is hard to be sure, especially as the code really needs to be tidied up.

Another option is that I intend, soon (but no estimated date yet), to start on release 2.0beta of the python API, and decouple this from the versioning of the data request content. That will be a chance to clear up the way the experiment specifications works.

martinjuckes commented 4 years ago

I've put a warning in (and hope to get 01.00.32beta out soon). There is a further complication in that and experiment can be associated with multiple tiers, depending on which MIP is requesting it. Consequently the warning will be a little vague .. but should provide a clear enough clue.

JamesAnstey commented 4 years ago

Thanks @martinjuckes. I agree, decoupling the versioning of the API and data request content could be useful.