Instantiation MappingFEField with hp::DoFHandler

[Doug]

Hello again,

I am trying to use MappingFEField to represent my high-order mesh points (which will then be deformed through optimization). Similarly to this thread High order mesh from Gmsh. However, I am using hp-finite element and I would expect different element geometric orders to exist for cells with different solution orders.

I see that MappingFEField is currently only instantiated with DoFHandler, and not hp::DoFHandler, so I tried to add it to the instantiation file "/fe/mapping_fe_field.inst.in". Unfortunately, it seems like the current MappingFEField implementation assumes that the finite element is not a FECollection, etc. and tries to directly operate on it. 

What would be the best way to have different element geometric orders, where I can control the metric degrees of freedom?

Doug

[Wolfgang Bangerth]

Doug,

> I am trying to use MappingFEField to represent my high-order mesh points
> (which will then be deformed through optimization). Similarly to this thread
> High order mesh from Gmsh

> <https://groups.google.com/forum/#!searchin/dealii/high$20order$20mesh|sort:date/dealii/8ta3DmMCwsE/0AKQVI_0AQAJ>.

> However, I am using hp-finite element and I would expect different element
> geometric orders to exist for cells with different solution orders.
>
> I see that MappingFEField is currently only instantiated with DoFHandler, and
> not hp::DoFHandler, so I tried to add it to the instantiation file
> "/fe/mapping_fe_field.inst.in". Unfortunately, it seems like the current
> MappingFEField implementation assumes that the finite element is not a
> FECollection, etc. and tries to directly operate on it.
>
> What would be the best way to have different element geometric orders, where I
> can control the metric degrees of freedom?

It does not greatly surprise me that it doesn't compile -- what isn't tested
generally doesn't work.

We'd of course be very happy to accept any patches to make things work. The
general approach to making stuff work is to *always* use hp::FEValues objects
to evaluate solution fields. You might want to look at some of the functions
in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to see
how they work and how the code is written to accommodate both kinds of DoF
handler classes.

A good strategy to implement these kinds of changes is to split things up into
a number of incremental changes. Each of these individually doesn't get you to
the end point, but fixes one roadblock at a time. I find it much easier to
work this way (using many individual pull requests to get to the final goal)
than to try and write one monumentally large one, principally because each
step individually can be sent through the test suite. (There are 23 tests
right now that use this class, so it's reasonably well tested.) If no tests
break, then it can't have been so wrong, and one can move on to the next
problem. I've definitely implemented things many times that took a sequence of
10 pull requests, each making incremental progress. Writing several new tests
in the process is definitely also helpful. I'd suggest you try that approach.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Doug Shi-Dong]

On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth wrote:

Doug,

It does not greatly surprise me that it doesn't compile -- what isn't tested
generally doesn't work.

Makes sense. 

We'd of course be very happy to accept any patches to make things work. The
general approach to making stuff work is to *always* use hp::FEValues objects
to evaluate solution fields. You might want to look at some of the functions
in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to see
how they work and how the code is written to accommodate both kinds of DoF
handler classes.

I think I should be able to get away with always constructing a high-order geometric grid for now, but I I'm guessing that it's not going to be the only hurdle I encounter with hp. Seems like the same philosophy applies to collections e.g. I should *always* use a FECollection of FESystem of FiniteElement since that seems to encompass all possibilities.

If I do end up needing those features, should I open an issue and ask to get it assigned to myself? And then refer to that issue for pull requests?

A good strategy to implement these kinds of changes is to split things up into
a number of incremental changes. Each of these individually doesn't get you to
the end point, but fixes one roadblock at a time. I find it much easier to
work this way (using many individual pull requests to get to the final goal)
than to try and write one monumentally large one, principally because each
step individually can be sent through the test suite. (There are 23 tests
right now that use this class, so it's reasonably well tested.) If no tests
break, then it can't have been so wrong, and one can move on to the next
problem. I've definitely implemented things many times that took a sequence of
10 pull requests, each making incremental progress. Writing several new tests
in the process is definitely also helpful. I'd suggest you try that approach.  

Thank you for the tip. I did not realise that pull requests could be used for "partial" features (as long as they don't break the code). This is my first large(ish) project where other students contribute to the code, and I'm trying to mimic the forking workflow of open-source projects. Will definitely recommend them to do pull requests more often to reduce merge conflicts.

 

[Wolfgang Bangerth]

> If I do end up needing those features, should I open an issue and ask to get
> it assigned to myself? And then refer to that issue for pull requests?

Yes. Here are a couple of examples for similar issues that require a lot of
work before they can finally be closed:
https://github.com/dealii/dealii/issues/3511
https://github.com/dealii/dealii/issues/1973
https://github.com/dealii/dealii/issues/1894
I hope yours doesn't take as many patches to finish as these ones :-)

> Thank you for the tip. I did not realise that pull requests could be used for
> "partial" features (as long as they don't break the code).

Yes, I do a lot of work that way where I "morph" the code into the direction I
need it.

> This is my first
> large(ish) project where other students contribute to the code, and I'm trying
> to mimic the forking workflow of open-source projects. Will definitely
> recommend them to do pull requests more often to reduce merge conflicts.

Yes, definitely pull frequently -- every time you start something. We merge
5-10 pull requests every day, with changes all over the place, and you'll get
behind very quickly if you don't frequently pull.

[Arthur Bawin]

Hello deal.ii community,

Sorry to pull an old thread, but I was wondering if there had been developments regarding the creation of a MappingFEField with an hp::DoFHandler.

I would need it for a simpler application, where all mesh elements have the same mapping order.

I'd be happy to look into expanding it myself, and I’d appreciate any advice on how to do it best (-:

Thank you,

Arthur

[Doug Shi-Dong]

Hi Arthur,

I haven't followed the development of deal.II so I'm not aware of whether you can now use hp::DoFHandler.

If you only need it for mesh elements with the same mapping order, you don't need hp::DoFHandler and can get away with the simpler DoFHandler as detailed here:
https://groups.google.com/g/dealii/c/8ta3DmMCwsE/m/0AKQVI_0AQAJ

I even have a working implementation here:
https://github.com/dougshidong/PHiLiP/blob/master/src/mesh/high_order_grid.h

There's a lot of spaghetti code for other purposes in there, but effectively, your mesh is now simply a field of x, y, z, just like any other simulation values.

Best regards,

Doug