Comments (9)
from climatemachine.jl.
I'm in favor of flattening. CamelCase generally is also fine with me. But constructs such as CLIMAAtmosDycore are hard to read. Underscores or hyphens would help here.
from climatemachine.jl.
Even just Atmos
might be sufficiently descriptive and memorable.
from climatemachine.jl.
@jkozdon Some more thoughts on this:
-
Directory hierarchy is useful where it reflects logical hierarchy. I propose we leave, e.g., Atmos/Dycore, Atmos/Parameterizations etc. Otherwise the root where Atmos lives will get very unwieldy soon (many model components, each with their own hierarchy...)
-
If we want to use Camel Case for directories, let's omit the CLIMA in front of Atmos etc.
-
Camel Case for modules and structs is also fine, for consistency with Julia.
-
But underscores in function and variable names increase readability, and I favor retaining those.
from climatemachine.jl.
This all sounds good to me. Maybe we can move the coding conventions document into CLIMA somewhere and update it using these ideas?
from climatemachine.jl.
re: @tapios
I suppose my default recommendation is that we start with the Julia style guide recommendations, and then specify deviations from that.
- Within Julia we can create submodules as well. So the unwieldiness could be managed there, if it made sense to one have a few core modules, say
AtmosDycore
andAtmosParameterizations
- Sounds good to me
- Sounds good
- This is the Julia style guide as well.
From [style-guide]:(https://docs.julialang.org/en/v1/manual/style-guide/index.html#Use-naming-conventions-consistent-with-Julia-base/-1)
- modules and type names use capitalization and camel case: module SparseArrays, struct UnitRange.
- functions are lowercase (maximum, convert) and, when readable, with multiple words squashed together (isequal, haskey). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch as a more efficient implementation of fetch(remotecall(...))) or as modifiers.
- conciseness is valued, but avoid abbreviation (indexin rather than indxin) as it becomes difficult to remember whether and how particular words are abbreviated.
from climatemachine.jl.
Thanks, @jkozdon. Following Julia style where it makes sense sounds good to me. Regarding directory structure, while I am in favor of flattening unnecessary hierarchy, I am not convinced we should flatten so much as to put AtmosDycore and Atmos etc. into one root. Several reasons:
-
Our code will be complex in the end, more comparable, say, to an OS kernel than to most Julia projects. Some structure will help (as it does, say, in the Linux kernel).
-
With the proposed convention, we would end up with complicated constructs such as AtmosParameterizationsRadiationRRTMG. I would find it helpful to have directory structure for it, rather than loading the names with the structure.
-
We will need some code in other languages, e.g., for radiation. Again, easier to drop it into a directory for radiation..
-
The atmosphere, ocean, land etc. models should work as standalone models in the end. It's easier to identify what one needs for these models if there is a directory tree for each of them, and directory trees for shared code.
That being said, I'm not sure we need hierarchies like Parameterizations/src (but if there is a good reason for having that, I can be convinced otherwise).
from climatemachine.jl.
I suppose the bigger issue than directory structure, is packages vs modules vs files.
Packages have to have the own src/
directory as well as a Project.toml
and (most of the time) Manifest.toml
. We can have modules within packages too, but these need not have their own src/
directory.
Naively, it seems to me that pieces we imagine being spun off at standalone components should be packages, and these need to be uniquely named.
One option would be that Atmos
is a package, with Dycore
, Parameterizations
, etc. as a submodule. To use these you would then type using Atmos.Dycore
or using Atmos.Parameterization
in the code.
Another option would be the AtmosDycore
and AtmosParameterization
are the packages, with possible submodules.
Packages we can version, whereas modules we cannot.
We also have the possibility of just dropping everything in files and using the include
mechanism everywhere, but this will cause problems with the namespace.
from climatemachine.jl.
@jkozdon All good points. I think you guys can make this structural decision, given that we need a standalone atmosphere model (both in global and LES configurations, which may differ slightly in terms of SGS models), and other standalone models. We will also want to use, e.g, various parameterizations in offline (single-column) mode, but I suppose that can be done whether they are packages or modules.
from climatemachine.jl.
Related Issues (20)
- Modify RHS parameter functions
- Missing documentation and errors in SurfaceFluxes.get_flux_coefficients HOT 4
- Implement driver for point jet on sphere
- Implement driver for shallow water setup on the sphere
- Bring triply-period do-nothing box flow driver into master
- Implement driver for dry baroclinic wave in a channel HOT 1
- Perform quality checks on current benchmarks & bring them into QA pipeline
- Single stack diagnostics clobbers some quantities
- Some ocean variables have characters that don't always render
- Slow AtmosModel when using balance-law problems HOT 6
- Inconsistent maxiter values in thermo dispatchers and inner constructors
- Enforce initialization of state.ρ as aux.ref_state.ρ in Anelastic1D model. HOT 3
- Grid imprinting in specific variables (per unit mass) due to filtering, and energy-momentum leakage HOT 2
- Burgers single stack tutorials all show the same figures
- Shear used in EDMF sources from precomputed args becomes negative HOT 7
- fall back on BalanceLaw method for eq_tends HOT 1
- Computation of gradients in a compressible SingleStack HOT 7
- calculation of soil properties
- update language in tutorials
- OrdinaryDiffEq.jl v6 LinearSolve.jl HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from climatemachine.jl.