Re: [deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775
On 3/19/19 4:17 AM, luca.heltai wrote:
> what would you think of a function in GridTools like
>
> GridTools::propagate_internal_manifold_ids(tria, disambiguation_function)
>
> that would loop over all cells, loop over all faces, check if the neighbor
> manifold id is the same of this cell, and
> i) the two ids are the same: assign the same id to the face (calling
> cell->face(f)->set_all_manifold_ids())
> ii) the two ids are different: set the id of the face to the return value of
> the disambiguation_function(id1, id2)
>
> disambiguation_function could be of type
>
> std::function )>
>
> and its default implementation could be
>
> std::function )> = [](const manifold_id , const manifold_id ){return
> std::min(id1, id2);}
You'd have to do the same for edges in 3d, where the situation is more
difficult because there may be an arbitrary number of adjacent cells. So maybe
the function should take a std::set?
I think that the min of ids is a rather arbitrary choice. Why not just return
invalid_manifold_id if the two ids are different? (Which could then be
interpreted as not setting anything for that face/edge -- or maybe that's what
should be set, I don't know.)
Best
W.
--
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775
Nicola,
what would you think of a function in GridTools like
GridTools::propagate_internal_manifold_ids(tria, disambiguation_function)
that would loop over all cells, loop over all faces, check if the neighbor
manifold id is the same of this cell, and
i) the two ids are the same: assign the same id to the face (calling
cell->face(f)->set_all_manifold_ids())
ii) the two ids are different: set the id of the face to the return value of
the disambiguation_function(id1, id2)
disambiguation_function could be of type
std::function
and its default implementation could be
std::function = [](const manifold_id , const manifold_id ){return
std::min(id1, id2);}
Would this address your needs?
L.
> On 15 Mar 2019, at 15:16, Nicola Giuliani wrote:
>
> I agree that the choice is ambiguous on the faces.
>
> However a practical problem remains, let's assume that a user wants to import
> a very big geometry with a lot of internal faces. Right now he would need to
> specify all the possible faces in the input file (with an increasing
> possibility of confusing the manifold ids).
> I agree he should (otherwise is a criminal) specify what happens when two
> different manifolds meet but if we have a face neighbouring two cells with
> the same manifold_id couldn't (or shouldn't) we assume the manifold of the
> face to be the same?
> Alternatively we could write a utility to transfer the manifold information
> to the faces, it should be "morally" the same of calling set_all_manifold_ids.
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775
I agree that the choice is ambiguous on the faces. However a practical problem remains, let's assume that a user wants to import a very big geometry with a lot of internal faces. Right now he would need to specify all the possible faces in the input file (with an increasing possibility of confusing the manifold ids). I agree he should (otherwise is a criminal) specify what happens when two different manifolds meet but if we have a face neighbouring two cells with the same manifold_id couldn't (or shouldn't) we assume the manifold of the face to be the same? Alternatively we could write a utility to transfer the manifold information to the faces, it should be "morally" the same of calling set_all_manifold_ids. Il giorno mercoledì 13 marzo 2019 08:32:31 UTC+1, Luca Heltai ha scritto: > > I believe the first point is a bug of the read_ucd function. > > I opened an issue for this (https://github.com/dealii/dealii/issues/7802) > > The second point, however, is a feature. What should you do when two > material ids meet? I think it is the responsability of the user to make > sure that the correct manifold id is associated to the correct face. > > Currently our read/write vtk functions (in the GridIn class) are the only > ones allowing full treatment material ids, boundary ids, and manifold ids. > > I’m not sure UCD format allows you to specify both material and manifold > ids for cells, and boundary and manifold is for faces. Maybe Andrea knows > better? > > L. > > > On 8 Mar 2019, at 15:15, Nicola Giuliani > wrote: > > > > PR 7775 has revealed some critical issues in the handling of manifold_id > in codim-1 domain. > > > > -) I believe that GridIn.read_ucd appears to ignore manifold ids > associated to the cells, it seems to me that the flag > apply_all_indicators_to_manifold_ids does not affect the manifold id for > the cell. This issue has never been seen because internally the material_id > was used. > > > > -) As far as I understand the default behaviour is to consider only user > specified manifold ids for the lines of a cell otherwise flat_manifold_id. > Would it make sense to use the cell->manifold_id instead of > flat_manifold_id? > > > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775
I believe the first point is a bug of the read_ucd function. I opened an issue for this (https://github.com/dealii/dealii/issues/7802) The second point, however, is a feature. What should you do when two material ids meet? I think it is the responsability of the user to make sure that the correct manifold id is associated to the correct face. Currently our read/write vtk functions (in the GridIn class) are the only ones allowing full treatment material ids, boundary ids, and manifold ids. I’m not sure UCD format allows you to specify both material and manifold ids for cells, and boundary and manifold is for faces. Maybe Andrea knows better? L. > On 8 Mar 2019, at 15:15, Nicola Giuliani wrote: > > PR 7775 has revealed some critical issues in the handling of manifold_id in > codim-1 domain. > > -) I believe that GridIn.read_ucd appears to ignore manifold ids associated > to the cells, it seems to me that the flag > apply_all_indicators_to_manifold_ids does not affect the manifold id for the > cell. This issue has never been seen because internally the material_id was > used. > > -) As far as I understand the default behaviour is to consider only user > specified manifold ids for the lines of a cell otherwise flat_manifold_id. > Would it make sense to use the cell->manifold_id instead of flat_manifold_id? > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775
Dear all, PR 7775 has revealed some critical issues in the handling of manifold_id in codim-1 domain. -) I believe that GridIn.read_ucd appears to ignore manifold ids associated to the cells, it seems to me that the flag apply_all_indicators_to_manifold_ids does not affect the manifold id for the cell. This issue has never been seen because internally the material_id was used. -) As far as I understand the default behaviour is to consider only user specified manifold ids for the lines of a cell otherwise flat_manifold_id. Would it make sense to use the cell->manifold_id instead of flat_manifold_id? Bests, Nicola -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
