Skip to content
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

Create new DMOD class for subset of config details from NextGen realization config #263

Closed
Tracked by #251
robertbartel opened this issue Jan 30, 2023 · 3 comments · Fixed by #316
Closed
Tracked by #251
Assignees
Labels
enhancement New feature or request maas MaaS Workstream

Comments

@robertbartel
Copy link
Contributor

robertbartel commented Jan 30, 2023

Create new, serializable DMOD class, similar in purpose to NgenRealization from ngen.config package. It should be composed of classes from ngen.config as well. The class will represent job config details provided by user, but it will not required certain information required by a NextGen realization config that DMOD can automatically determine.

The prime example is forcing configuration details, since these are subject to the details of the associated DMOD forcing dataset.

@robertbartel robertbartel changed the title Create new DMOD class, similar in purpose and composition to NgenRealization from ngen.config package, to represent only those job config details provided by user via GUI or CLI when requesting a job Create new DMOD class for subset of config details from NextGen realization config Jan 30, 2023
@robertbartel robertbartel added enhancement New feature or request maas MaaS Workstream labels Jan 30, 2023
@aaraney
Copy link
Member

aaraney commented Jan 30, 2023

For history sake, this issue surfaced out of conversation in #251.

@robertbartel robertbartel self-assigned this Jan 30, 2023
@robertbartel
Copy link
Contributor Author

Changing the status of this issue to Blocked. Much of the work is done and pushed to the i/post_agu22/5/request_config branch in my fork. However, it really needs the Pydantic work (#279) finalized and committed first.

@robertbartel
Copy link
Contributor Author

This is no longer blocked.

After getting back into this, it looks like it might now make more sense to finish the Pydantic stuff in #279 first. The implementation I have thus far has an intermediate serialized state expected to be generated by Pydantic at the GUI but not aware of it at this level, which isn't ideal.

There needs to be some more (fairly complicated) rebasing done for #279, though. Going to give that a shot first, and if it looks too complicated, I will return to this in its less refined first form, which we can improve later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request maas MaaS Workstream
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants