Add option to project DG fields when outputting.

[jrper]

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?

[jrper]

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?

[stephankramer]

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.

[jrper]

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.

[jrper]

Having said all that @gdeskos has sometimes intimated he'd approve of a femtools library which was less symbiotic.

[gdeskos]

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> .