Default "calendar information" in splits should be the one coming from the chunk?

[ainagaya]

Hi @dbeltrankyl , @kinow ,

This is not urgent at all, but I wanted to explain a "use case" that I'm having.

In the DestinE model-only workflow we have 2 jobs running at split level: TRANSFER and WIPE. The transfer has to run at small splits when the resolution is high because otherwise, the amount of data that we attempt to transfer is too much for the server. So we define the job to run with SPLITS: auto and the EXPERIMENT.SPLITSIZE, etc variable according to this limitation, and one EXPERIMENT configuration can be loaded depending on the resolution of the simulation (I haven't done this yet, in case you check it, but it's my idea). So we run, for example, monthly chunks with 2-days splits, that are adjusted in each chunk.

The WIPE task was also running with the same granularity, but I don't think that we have these memory limitations, so I wanted to reduce the number of jobs, and I tried to define JOBS.WIPE.SPLITS=1 instead of auto. This allowed me to keep the same template that we had (that is based on splits) but with a single job. In the GUI, I see that the start and end dates are correct:

But then, when I try to use the SPLITS_* variables (the ones that have calendar information) I get the information coming from the EXPERIMENT section:

SPLIT_END_DATE=19900102
SPLIT_FIRST=TRUE
SPLIT_SECOND_TO_LAST_DATE=19900101
SPLIT_START_DATE=19900101

When, according to the GUI, those values should be the ones "inherited" from the chunk.

My understanding is that the splits were not designed to work with calendar information in the beginning, and that the way of "activating" the calendar is to use auto. I'm suggesting that, if it's not too complicated to implement, when the job split variable (in this case JOBS.WIPE.SPLITS) is not auto, the calendar information should be inherited from the chunk. So, if there were 5 "hard-coded" (not auto) splits, all of them would have the same calendar information as the chunk.

Otherwise, if this is too complicated, I would suggest that the GUI information is revised.

As I said this is not urgent!!

Best,

PD: I just realized when writing this that this will conflict with the EXPERIMENT.SPLIT* variables defined in the application's workflow (@franra9 , @ialsina) if we run end to end.

[ainagaya]

PD: I just realized when writing this that this will conflict with the EXPERIMENT.SPLIT* variables defined in the application's workflow (@franra9 , @ialsina) if we run end to end.

That was not correct, we can define the splitsize at job level.