-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add option to project DG fields when outputting. #149
base: main
Are you sure you want to change the base?
Conversation
I've added a basic test to this, which just checks the sanity of the output vtus. @stephankramer any chance of a review, or should I find someone else to take a look? |
To repeat what I said offline: this is great. We should have done something about this long time ago. Main issue with the current PR is that it pulls in too many dependencies for vtk_write_fields() which should remain available as a low level routine. This is not only reflected in the forward interface in the halo code, but there is also a circular module dependency: fefields -> vtk_interfaces -> solvers -> fefields - I'm not even sure how this compiles tbh. A general problem with the fluidity code is its lack of modularity. Although I don't think we're ever planning to publish for instance femtools as a separate library, with a large code base if you don't divide it up in layers that in principle could be used independently, it just becomes an unmaintainable mess. Unfortunately these layers currently only exist vaguely in our heads. I'm currently rejigging this a little so that the projection stuff happens in vtk_write_state_new_options() and leave vtk_write_fields with its current functionality. Ideally I would rewrite vtk_write_fields() and restrict it even further to only allow fields to be on the "model mesh" (horrible word btw), and get rid of all the automagic dg-ifying and remapping, but that would require checking over a hundred vtk_write_fields calls - so probably never going to happen. |
That all makes sense to me. My only excuse for the name schemes is inheriting what was there before. I don't think "model mesh" is one of mine. |
Having said all that @gdeskos has sometimes intimated he'd approve of a femtools library which was less symbiotic. |
Yes ! I actually think of building a separate solver from scratch using
femtools instead of having to modify the mess called fluidity. I want to
write a dg solver (2D or 3D) which will be able to properly introduce
higher order explicit time-marching schemes such as the explicit
Runge-kutta 4th or some IMEX scheme similar to the ones used in Nektar++.
Most of the routines are already there within the femtools library. I tried
recently to hack the Low Storage explicit RG3 in momentum dg and found out
that the momentum_solver routine takes as arguments pointers that I am not
even using (e.g. reduced models etc).
I dont know if anybody else is also supportive of this idea.
Yorgos
…On Wed, Apr 19, 2017 at 4:51 PM, James Percival ***@***.***> wrote:
Having said all that @gdeskos <https://github.com/gdeskos> has sometimes
intimated he'd approve of a femtools library which was less symbiotic.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#149 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APALdNmlysKi6Dy8zNu20q2eSLTL4WHeks5rxi2CgaJpZM4MYlLB>
.
|
I think this is one of the things on @stephankramer's wishlist. This version is only weakly optimised, and I can't think of a good test for buildbot. Does anyone have any ideas?