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
I wonder if it may be a good idea to add a generic, user-definable 'parameters' field in Model.
The main purpose of this field would be to provide the user with more flexibility for boundary condition and forcing functions. Consider the implementation of a simple sponge layer in a script:
const dTdz =0.01const μ₀ =0.02@inlineμ(z, Lz) = μ₀ *exp(-(z + Lz) /0.05Lz)
@inlineT₀(z) = dTdz * z
@inlineFT(grid, U, Φ, i, j, k) =@inbounds-μ(grid.zC[k], grid.Lz) * (Φ.T[i, j, k] -T₀(grid.zC[k]))
model =Model(forcing=Forcing(FT=FT), ...)
This works, of course. However, it requires the global consts dTdz and μ₀ in order to compile on the GPU. This prevents users from, for example, defining a function of the form create_and_run_model(μ₀, dTdz, other_parameters...). The only way to set μ₀ or dTdz is by defining them as global consts; therefore a new script (or argument parsing via ArgParse and bash scripting) is required for each new run.
I feel this is a potentially major limitation to current and future automation and we should attempt to find a solution to address the problem.
One partial solution is to add a field parameters to the model. This field is then passed down into calculate_interior_source_terms! and the boundary condition algorithm to be used, if desired, within a user-defined functions. In this case, the above pattern could become:
@inlineμ(z, Lz, μ₀) = μ₀ *exp(-(z + Lz) /0.05Lz)
@inlineT₀(z, dTdz) = dTdz * z
@inlineFT(grid, U, Φ, i, j, k, params) =@inbounds-μ(grid.zC[k], grid.Lz, params.μ₀) * (Φ.T[i, j, k] -T₀(grid.zC[k], params.dTdz))
model =Model(forcing =Forcing(FT=FT), parameters=(μ₀=0.02, dTdz=0.01), ...)
We need not restrict the type of the field parameters; we can simply add
I like this! I do agree about the current setup limiting future automation and reproducibility.
So I guess the idea is that params is completely user-defined and is available to forcing functions and boundary conditions. So it shouldn't be used by the Model itself.
Right --- I think any required fields would either complicate it's specification or limit how it could be used, so I think it makes sense that it's either user-defined, or nothing.
I'll go ahead an open a PR if we think this is a good idea (and that parameters is a good name).
I wonder if it may be a good idea to add a generic, user-definable 'parameters' field in
Model
.The main purpose of this field would be to provide the user with more flexibility for boundary condition and forcing functions. Consider the implementation of a simple sponge layer in a script:
This works, of course. However, it requires the global
const
sdTdz
andμ₀
in order to compile on the GPU. This prevents users from, for example, defining a function of the formcreate_and_run_model(μ₀, dTdz, other_parameters...)
. The only way to setμ₀
ordTdz
is by defining them as globalconst
s; therefore a new script (or argument parsing viaArgParse
and bash scripting) is required for each new run.I feel this is a potentially major limitation to current and future automation and we should attempt to find a solution to address the problem.
One partial solution is to add a field
parameters
to the model. This field is then passed down intocalculate_interior_source_terms!
and the boundary condition algorithm to be used, if desired, within a user-defined functions. In this case, the above pattern could become:We need not restrict the type of the field
parameters
; we can simply addAnd set it to
nothing
by default in theModel
constructor. The user may provide any kind ofparameters
they wish.The text was updated successfully, but these errors were encountered: