akshaysridhar
commented
4 years ago I suppose the namelist idea implies that each experiment by accompanied by its own namelist or config file, such that the <experiment> file contains the initialization, whereas the <experiment config> file basically lists the AtmosModel components. I'll walk through the functionality that the above namelist brings in (of course the actual form varies among models) and see how that compares with CLIMA right now ..
Agreed on diagnostic variable specification, this currently doesn't exist at the experiment level. Currently these are specified in the diagnostic source code files themselves, with an intent to upgrade this and allow users to design diagnostic variable groupings.
"conditional_stats": {
"classes": [
"Spectra"
],
"frequency": 600.0,
"stats_dir": "cond_stats"
},This exists as a source term prescription, perhaps a way to clarify this would be to include SpongeRelaxation as an explicit subcomponent of AtmosModel instead of passing this as a component of the Source tuple.
"damping": {
"Rayleigh": {
"gamma_r": 0.002,
"z_d": 500.0
},
"scheme": "Rayleigh"
},This already exists as a subcomponent of AtmosModel , and I don't see how using a namelist makes this any clearer than using SmagorinskyLilly(coefficient) or ConstantViscosityWithDivergence(coefficient) in the AtmosModel specification. Besides, CLIMA has a pretty clear distinction between an (equivalent, we don't work in entropy here) q source vs q flux term, and right now I think it makes sense to maintain that distinction.
"diffusion": {
"qt_entropy_source": false
},The variable choice component is missing from experiments, but the field type ( dump-field vs horizontal averages) is available , selectable from the Diagnostics configuration struct at the experiment level. [missing docs]
"fields_io": {
"diagnostic_fields": [
"ql",
"temperature",
"buoyancy_frequency",
"viscosity"
],
"fields_dir": "fields",
"frequency": 3600.0
},The grid specification exists at the experiment level through the config_setup() function hook.
"grid": {
"dims": 3,
"dx": 35.0,
"dy": 35.0,
"dz": 5.0,
"gw": 5,
"nx": 96,
"ny": 96,
"nz": 300
},This would presumably become an AtmosModel component similar to the turbulence = component. The Phase-Partitioning is currently tied to the moisture.jl MoistureModel component.
"microphysics": {
"ccn": 100000000.0,
"cloud_sedimentation": false,
"phase_partitioning": "liquid_only",
"scheme": "None_SA"
},The spatial and temporal discretisations are explicitly specified through the polynomial order N and the time stepper choice in the solver_setup level via the experiment file.
"momentum_transport": {
"order": 7
},Currently in the diagnostic configuration struct
"output": {
"output_root": "./"
},Pending PR, presumably applied through a callback of some sort.
"restart": {
"frequency": 600.0,
"init_from": false,
"input_path": "./",
"output": true
},See AtmosModel turbulence= component.
"sgs": {
"scheme": "Smagorinsky"
},This is currently part of the moisture subcomponent in AtmosModel
"thermodynamics": {
"latentheat": "constant"
}, "time_stepping": {
"cfl_limit": 0.7,
"dt_initial": 1.0,
"dt_max": 4.0,
"t_max": 14400.0,
"ts_type": 3
},Here, I see disconnected components (assuming the copied code is a direct representation of an existing namelist line-by-line) why are output-dir, visualization frequency and output variable lists not grouped (in contrast with CLIMA DiagnosticConfiguration) ? Same with the time-stepping component above, ts_type = 3 is not at all as clear as ode_solver = LSRK144NiegemannDiehlBusch
"visualization": {
"frequency": 1000000.0
}
}One thing not apparent from the namelist file above is the set of boundary conditions used in the problem. My interpretation of the current driver_config and solver_config is that we're trying to decouple the physics (equations, diffusion, sources, init_cond) from the configuration related material (diagnostic list, diagnostics interval, problem domain and resolution). Describing things like entropy sources and diffusion models in a namelist file, but the boundary conditions elsewhere seems inconsistent to me, but perhaps people who have used a variety of different atmospheric models / GCMs can help me see the reasoning behind such a design choice. In the end we need to make it simple enough for a new user to know what they just ran by simply downloading and running CLIMA, and how they can make basic modifications to it (namelist JSONs or unique experiment files or however we choose to do it)
I suspect a strong effort at documentation within CLIMA will fix a lot of these namelist concerns.
szy21
smarras79
claresinger
charleskawczynski
kpamnany
glwagner
Description
Terminology: in the following, "driver" indicates any setup file contained in
experimentsand not theDriver.jlfile.I'd like to go back to the open discussion from last summer and fall about the use of a namelist file that contains the main and only informations needed to execute CLIMA.
As of now, although the drivers have been greatly cleaned up and minimized in the past few months, they still require a user to be very familiar with Julia code; not only, the user should also be familiar with the guts of CLIMA if he/she really wants to be able to modify the driver without breaking the code or without removing relevant information from it.
To avoid this issue, it is standard practice in the atmospheric (WRF, CM1, Pycles, NUMA, etc.) and CFD (OpenFOAM, Nektar++, etc.) communities to use a
namelistfile (often simply called input file) that does not contain any code. A namelist is nothing else than only a list of parameters that the code will simply read and do what it should. These namelists can be as simple as a sequential list of parameters, or more hierarchical such as the one used by Pycles which is a JSON file.For example, here is the one used by Pycles:
Additional context
To put this in perspective: don't put yourself in the shoes of the PhD student or post-doc who works 27 hours/day, 8 days/week and could possibly figure it out, but in those of a 70yr old Caltech full professor, retired, who is bored of being home during the lockdown and decides to download and run CLIMA to write a paper on Climate change. The poor retired professor will not try to figure out how to read Julia code, but, rather, will expect a text file with some some self-explicative variable name with an assigned value or keyword that can be changed without worrying whether that is a source or a flux.
For CLIMA Developers