Remeshing a vtk (vtp) file with a size map

User Help
#1

Hello everybody,

I’m new using mmg. I need to remesh meshes in vtp format, controlling the cell size according to a metric. So as I understood, I need to use a size map. However I can’t succeed to make mmgs take this size map into account.

For now I already just try to remesh with a constant size. If I provide this constant size at command line (mmgs_O3 test.vtp -hsiz .001), it works as expected

However if I save this same size in point data, suffixed with :metric (as explained in the prerequisite section)

> mesh.point_data["size:metric"]
pyvista_ndarray([0.001, 0.001, 0.001, ..., 0.001, 0.001, 0.001])

Then running mmgs_O3 test.vtp just remeshes ignoring the size map.

I note however that mmgs does read this field, as if I create another one suffixed with :metric, it fails with an error ## Error:MMG5_count_vtkEntities: 2 metric fields detected (labelled with a string containing the 'metric' keyword)..

So, I must be missing something, but can’t find what. What do I miss for mmgs to take this size into account?

Thank you in advance!

Edit: ah just found something. Actually I have cell data on this mesh, and in verbose mode, mmgs complained that “SEVERAL SOLUTION => IGNORED: 2”. If I delete the mesh data, remeshing works taking the size map into account.
So I guess I found my answer, but why is this cell data blocking remeshing? Its name doesn’t contain :metric.

#2

Hi Eino and welcome to this forum,

When I have implemented VTK I/Os, I have tried to make Mmg behave the same way with VTK files as with the files it reads by default (the Medit files).

At Medit file format, data are provided in a different file (.sol file) than the mesh (.mesh file). It allows to associate multiple data that have different meanings (s.a. solution fields and metric for example) to the same mesh.

Mmg opens by default both files if they have the same basename (because the .sol file may contain a metric, a level-set or a displacement) but sometimes, the user’s solver has saved the mesh and an associated solution field so when Mmg is run on the .mesh file, a solution file that should be ignored is opened too. To overpass this issue, we have made the assumption that the .sol file opened by Medit contains only one field, the metric, the level-set or the displacement one. If the file contains more than one field, it is considered as a ‘solution field’ and ignored by Mmg (but Mmg doesn’t raise an error).

It is the main reason why multiple data fields provided inside VTK files are ignored (without making Mmg fail).

Another one is that, as we don’t provide data field interpolation from input mesh onto the final one, it seems cleaner to me that the user does not provide us useless fields. Maybe there is also another difficulty in the implementation, but I don’t remember :sweat_smile: .

If you think that the behaviour or the message is not enough clear for the users, do not hesitate to propose a correction, either with a PR (warmly welcome) or with suggestions (in this case, it will take longer to be implemeted and it can be useful if you can provide your .vtp or .vtk file with multiple fields).

Best Regards,
Algiane

#3

Hi Algiane,
thank you for your answer. That makes sense. Indeed perhaps the message could be improved, if it can gain some time to other users; I will try to propose a better one in a PR. Actually I wonder if it wouldn’t be more straightforward to just fail? Thus the behavior would be aligned to the case where multiple :metricfields are provided. What do you think?

And your message also kind of answers my other question (that I hadn’t asked yet :grinning:) : would it be possible to interpolate the values of another field to the new mesh.
I do it with vtk after remeshing, but the result is not so good, as at some places the geometry have multiple close layers, thus the closest point is not always the one the value should be interpolated from. The ideal solution would be to interpolate during remeshing, so the values could “follow the edges”, maybe averaged, but never passing from one layer to another.

But from you answer I take it wouldn’t be at all easy to implement. (I started looking at MMG5_mmgs1, and that’s also what seemed to me). But if you have any lead idea about adapting the lib for interpolating another value, don’t hesitate to keep me posted, I could try to tackle the problem in a fork.

Best regards,

Eino

#4

About the warning message, it could be something like this, what do you think?

That displays a message like:

Warning: SEVERAL SOLUTIONS FOUND (4): IGNORING ALL

#5

Hi,

You’re right, it is probably simplier to just fail in fact (so the user don’t have bad surprises).

In Mmg we doesn’t provide the interpolation of the solution. The main reasons are that:

  • lot of users implement their own interpolation methods (because it is closely linked to the numerical method that is used);
  • implementing one interpolation method (P1 interpolation for example) will open the door to many requests for additional developments (HO interpolation, conservative interpolation, etc);
  • interpolation schemes and remeshing both research areas in their own right (even if closely linked)…

Regarding your issue, a first idea can be to test a different software (using a different algo may help). You can for example try the mshint software of P. Frey. It takes Medit files so it should be fast to test (you can use Mmg to convert files from/to vtk).

Probably you will have the same issue, in this case, I can give you some hints (but that ask to implement things).
In fact we have only implemented the P1 interpolation for our parallel 3D volume remesher (ParMmg) because the localisation is very hard to perform for user once the mesh has been redistributed. We have encountred difficulties similar to yours in the localisation of points in the presence of thin layers. To solve the issue, we have added, with a given precompiler flag, a new field inside the point structure (see libmmgtypes.h file). It is used in mmg3d only, in this case, the src field of a point ip is filled by the index of a point “close to” ip. Then the localization routines implemented in ParMmg (in locate_pmmg.c) uses this value as a starting point for the research. It allows to speed up the localization process and to avoid some issues such as the thin layers one.

Depending on your time and how interpolation errors are annoying for you, you may try to adapt mmgs to fill and update the src value (with the mmg3d example, it should be pretty easy and fast I think) and mshint so it uses the src point as starting point of the localization algo (I have no idea if it is complicated).

Best Regards,
Algiane

#6

Hi Algiane,

Thank you for the explanation, it makes sense. Eventually I re-interpolated data another way, by using pyvista.

As for the case of multiple solutions, I changed the behavior to fail if there is more than one solution found. My change is visible here Comparing MmgTools:master...eino:feature/multiple-solutions-message · MmgTools/mmg · GitHub
Does it look good for you? If so, I can open it as a PR.

Best regards,

Eino

#8

Hi @eino ,

I am glad that you have found another way to interpolate your data.

Thanks a lot for the proposition of modification: it seems ok for me, do not hesitate to open the PR.

Have a nice evening,
Algiane

#9

Hi @Algiane ,

Thanks, I opened PR for this change. :+1:

Have a nice day,
Eino

#10

Thanks a lot,

Have a nice day too.