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

Ability to pass additional parameters into enriched_mesh_seq constructor from child class of GoalOrientedMeshSeq #235

Open
acse-ej321 opened this issue Nov 23, 2024 · 2 comments
Labels
question Further information is requested

Comments

@acse-ej321
Copy link
Collaborator

I currently have a child class inheriting from :class:~.GoalOrientedMeshSeq where get_initial_conditions, get_solver and other base class functions are dependent on a parameter dictionary. Currently this works well with the methods in associated with :class:~.MeshSeq and :class:~.AdjointMeshSeq but breaks with the get_enriched_mesh_seq method of :class:~.GoalOrientedMeshSeq as it does not allow for passing of any additional parameters which may be associated with the child class.

The initial question I have is, would it make more senses for me to refactor my derived class or would it make sense to refactor get_enriched_mesh_seq to be more flexible to passing additional parameters?

@acse-ej321 acse-ej321 added the question Further information is requested label Nov 23, 2024
@jwallwork23
Copy link
Member

I think it'd probably be fine to change the base get_initial_condition and get_solver methods so that they accept **kwargs and pass those to _get_initial_condition and _get_solver, respectively. Would that be sufficient for your issue?

@ddundo
Copy link
Member

ddundo commented Nov 23, 2024

Duplicate of #97?

On a semi-side note, I think it might be good to even require the "object-oriented" approach. I think it's very neat. That would also solve #22 nicely

Edit: actually I think the proper way to do this would be to introduce a Solver helper class, which would be separate from MeshSeq. So I opened #238. Enriching the mesh shouldn't affect the solver at all, so I think adding these options to pass **kwargs would be counter-productive, since it's not the underlying issue. I opened #239 with a quick and dirty example of how that would look. If you like it, I'm happy to do it properly :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
Development

No branches or pull requests

3 participants