You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is not a problem yet, but it's something we are anticipating it may become. Currently we are working on reading datasets natively, and the original idea was to group them on one project, native6. However, in practice many of these datasets have their own folder structure or name convention, and it seems it makes more sense to implement as separate projects (see #494 for discussion on this topic). We anticipate that this policiy could increase the number of datasets enough that it clutters the configuration files. Furthermore, it requires users to keep track of the datasets and update their configuration file accordingly.
However, in practice many users share a configuration, as they work in a few HPC's. We are already anticipating this and handling it by having different DRS's for these machines in the config-developer.yml file, and by providing by default configurations that users can uncomment in config-user.yml.
This process could be simplified if users had only to define once in which machine they are working, so that DRS would be used by default. Any exception that a user would need could be specified separatedly.
E.g, from:
# Site-specific entries: Jasmin
# Uncomment the lines below to locate data on JASMIN
drs:
CMIP6: BADC
CMIP5: BADC
CMIP3: BADC
CORDEX: BADC
OBS: BADC
OBS6: BADC
obs4mips: BADC
ana4mips: BADC
to
drs:
# Site-specific entries:
# Uncomment the lines below to locate data on JASMIN
default: BADC
Exceptions could be handled by using the current format, which also would make it backwards compatible
drs:
default: DKRZ
CORDEX: BADC
A similar approach could be used with rootpaths, although it would require defining the routes somewhere else.
An alternative to the "default" field would be to use lists. For example, DKRZ currently has one main roothpath, two main DRS and a few exceptions:
Personally I prefer having a default, so updates in the repository configuration files are immediately and seamlessly available to the user. I also find using lists a bit clunky and difficult to read.
Another solution can be found in #795, which also contains a collection of related issues and suggestions for a redesign of the configuration files.
Would you be able to help out?
I currently feel this is very low priority. As I said before, this is currently not an issue and I'm only opening this for discussion and record-keeping as we anticipate it may be.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This is not a problem yet, but it's something we are anticipating it may become. Currently we are working on reading datasets natively, and the original idea was to group them on one project,
native6
. However, in practice many of these datasets have their own folder structure or name convention, and it seems it makes more sense to implement as separate projects (see #494 for discussion on this topic). We anticipate that this policiy could increase the number of datasets enough that it clutters the configuration files. Furthermore, it requires users to keep track of the datasets and update their configuration file accordingly.However, in practice many users share a configuration, as they work in a few HPC's. We are already anticipating this and handling it by having different DRS's for these machines in the
config-developer.yml
file, and by providing by default configurations that users can uncomment inconfig-user.yml
.This process could be simplified if users had only to define once in which machine they are working, so that DRS would be used by default. Any exception that a user would need could be specified separatedly.
E.g, from:
to
Exceptions could be handled by using the current format, which also would make it backwards compatible
A similar approach could be used with rootpaths, although it would require defining the routes somewhere else.
An alternative to the "default" field would be to use lists. For example, DKRZ currently has one main roothpath, two main DRS and a few exceptions:
Which could be expressed as:
Personally I prefer having a default, so updates in the repository configuration files are immediately and seamlessly available to the user. I also find using lists a bit clunky and difficult to read.
Another solution can be found in #795, which also contains a collection of related issues and suggestions for a redesign of the configuration files.
Would you be able to help out?
I currently feel this is very low priority. As I said before, this is currently not an issue and I'm only opening this for discussion and record-keeping as we anticipate it may be.
The text was updated successfully, but these errors were encountered: