generated from NOAA-OWP/owp-open-source-project-template
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typo in formulation model constraint #32
Labels
Comments
@hellkite500, I can get a PR in for this on Monday. If I forget, just ping me. |
@aaraney ping? |
Thanks for the ping, @hellkite500. Ill get that in now that #30 is merged. |
aaraney
added a commit
to aaraney/ngen-cal
that referenced
this issue
Nov 14, 2022
12 tasks
robertbartel
pushed a commit
to robertbartel/ngen-cal
that referenced
this issue
Mar 31, 2023
aaraney
added a commit
to aaraney/ngen-cal
that referenced
this issue
Apr 4, 2023
aaraney
added a commit
to aaraney/ngen-cal
that referenced
this issue
Jul 24, 2023
aaraney
added a commit
to aaraney/ngen-cal
that referenced
this issue
Jul 24, 2023
After working through #34, it was decided that model_name as a discriminator isn't required, and has been dropped in that PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ngen-cal/python/ngen_conf/src/ngen/config/formulation.py
Line 8 in fdca562
This should be
discriminator
. Likewise, the discriminator should bemodel_type_name
notmodel_name
.model_type_name
is the alias formodel_name
, meaningmodel_type_name
is the key in the configuration file.Edit:
While this was an issue, by correctly spelling
discriminator
, this forced allmodel_type_name
fields to be typeLiteral
. This is okay in most cases, however it is not desirable forMultiBMI
.MultiBMI
'smodel_type_name
field should not be constrained like the other BMI model pydantic model types.However, there still needs to be a way to determine the correct pydantic model variant from the union of formulations,
KnownFormulations
. Thename
andmodel_type_name
fields are used for this purpose.name
corresponds the bmi adapter name used by that model (e.g.bmi_fortran
) andmodel_type_name
roughly corresponds to the model name (e.g.NoahOWP
). For non-multi bmi models, thename
andmodel_type_name
are constant values (e.g.bmi_fortran
andNoahOWP
for theNoahOWP
pydantic model). In the case of theMultiBMI
pydantic model, only name is a constant value,bmi_multi
,model_type_name
can be any valid string.However, it feels tedious that it would be required to specify these constants when programmatically creating a for example, a
NoahOWP
instance. For this reason, these constants are not required when creating aKnownFormulations
type. Likewise, it is possible to pass aKnownFormulations
instance when creating aFormulation
object. However, to deserialized intoFormulation
object, it is required thatname
andmodel_type_name
are present for non-multi bmi types and ,potentially only,name
it equals bmi_multi`.The text was updated successfully, but these errors were encountered: