#750 Prametrized boundary not working for ALUSimplexGrid<2,2>
Metadata
| Property | Value |
|---|---|
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Mar 2, 2010 15:56 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | Mar 4, 2010 13:19 |
| Closed by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Closed at | Mar 4, 2010 13:19 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Both issues are fixed in r6376 |
Description
If an ALUSimplexGrid<2,2> with boundary parametrization is created using BoundarySegments and the gridfactory this results in a segfault. If the example-projection.dgf from the dgf format doc is used the following error arises:
InvalidStateException: You can only add one globalProjection or projections for each face, but not both
You can varify this with the attached test case either without argument or with '-coarsegrid example-projection.dgf'.
Both problems arise with up-to-date dune-grid and alugrid.
Attachments
Activity
Valgrind does not show any memory corruption for gmshtest-alugrid with curved2d.msh. However this does not say anything since curved2d seems to use 6-node triangles and the gmsh reader does not insert BoundarySegments for them. See the result of the updated test to be called with
./gridfactory -gmshfile curved2d -refine 1
Attachments
Hi Carsten,
the first thing is, that you need to insert the vertices at first. The boundarySegment method needs the coordinates of the vertices. Then the projection seems not to be compatible with global projection created inside. To check this it would be better to have the GmshReader inserting the boundarySegments. When this is implement I'll have a look again.
Sorry, could you exlain what you mean by 'the other boundary projection' and 'Then the projection seems not to be compatible with global projection created inside.'
IMHO, there is no real need for BoundaryProjection if dgf supports BoundarySegments.
However the documentation says that it works for alugrid and the example file is the one from the docs. So it should work.
I just discovered that the manual insertion of BoundarySegments tries to insert squares. Sorry for this. With triangles you now get the helpfull 'Fucking bnd segment' error.
This happens for the insertion orders vertices/elements/segments and vertices/segments/elements.
An updated test is attached.
Attachments
-
I thought it might be more helpful than the 'Fuck gmsh' output, what do you think ;).
The error is that the local and global mapping of the internal created mapping do not give the same results and thus the projection cannot work. I don't know why this happens. The local2global mapping uses the GenericGeometries, so it should usually work. I would like to have the gmsh test ready rather then some manually generated BoundarySegments. On the other hand I' m not really interested in those things. That is why I wait until the gmsh test is ready.
If you implement BoundarySegments in DGFParser, then DGFParser will also be support these things, if not, not. Simple as that.
-
The decoupling of the expression parser is one thing.
The disfunctional BoundaryProjection is due to (what I mentioned above) the fact that this methods are not interface methods and that's why Martin and I implemented these methods slightly different. It is not a big thing to change this in ALUGrid. But it might be time consuming, time I don't like to spend on things I don't need. If you really need this feature I can explain you what to do and you should be able to implement this.
The bug with the boundarySegment I have no Idea what could be wrong.
If alugrid+dgf+BoundaryProjection is currently not supposed to work we should remove the BoundaryProjection related methods either from the dgf parser for alugrid or even from the grid factory for alugrid - depending on where the problem originates. (As far as I understand it's the dgf parser.)
IMHO if BoundarySegment are supported (perhaps also for dgf) we could even completely drop the BoundaryProjections.
I think the boundary segment / boundary projection stuff is still quite non-standard and only in Berlin (i.e., 3 month ago) it was decided which of the two ways to use. Moreover, the interface is still pretty unstable, so I would understand everyone not fully supporting the BoundarySegment stuff. There is, as of today, no road map on how we want to support these features. For example, I remember that there was some discussion on how to handle boundary segments in parallel (i.e., how to load balance them). I think this need to be thought out before we proceed any further.
You could, of course, argue that such unstable features should not yet be in the release branch. But that would mean a lot of extra work to remove such features that can be disabled by not using them.
So, if there are people who need this stuff, I would suggest a meeting of the people interested in those features. This meeting then should think the problems through, make a proposal on how to implement this stuff and provide the necessary tests (a reference implementation would not hurt, either).
The insertBoundarySegment method is part of the GridFactory since it was introduced about 2 years ago. This has been done following a decision on the Berlin meating in 2008. So I thought BoundarySegements are part of the interface for a long time (but only supported by UGGrid). The sequential version is also working for a long time in UGGrid.
Since the descision on last years meating the sequential interface seems to be fixed. The new discussion is all about how to extend this to the parallel case. Are there still open qeustions regarding the sequential interface ?
If yes, we should mark the interface as unstable. If not we should fix the Alugrid implementation now or postpone this until there is a definite descision on the full parallel interface.
Since alugrid seems to support boundary parametrizations in pricipal it would be very nice to be able to use this feature at least with sequential grids. Of course this is up to the Alugrid and dgf-parser maintainers ;-)
-
As I said, it wasn't difficult to implement the BoundaryProjection stuff in ALUGrid. In revision 6372 of the trunk it should work with the above example-projection.dgf. I also add a 3d example (for ALUCubeGrid) DGF file.
The problem with the boundary segments is still unsolved.
Apart from that I agree with Martin.
Attachments
Does this also imply that we need them in the dune interface of alugrid/alberta? Wouldn't it be nice to have one interface in dune that is wrapped to what ever is interally (as you already did)?
Having an alternativ, equivalent method might seduce the user to use this although he could use the compatible standard method.
Btw. thanks for the quick fix for the BoundaryProjection!
-
Interfaces should only describe the minimal functionality available. We should not restrict ourselves from adding features to special implementations, because this is the only way new features can be added and eventually become interface methods. Moreover, highly specialized implementations, such as the DGF parser, should always be free to use whatever method is best suited to them.
-
Of course, as mentioned more than once if I have a projection given as an analytical function (which is exactly the feature of the DGFParsers Projection block) it makes no sense to add number_of_bnd_segments boudnary segments although I only need one object, the global projection. Because of this, the boundaryProjection methods are available.
-
Currently, in a DGF file only such projections can be specified. Of course, we can add a ProjectionToSegment wrapper, just to wrap this again by a SegmentToProjection wrapper. But obviously, this is a waste of runtime, floating point precision and memory. Moreover, the ways in which the DGF parser can read boundary segments is not part of the GridFactory interface.
As to the stability of the interface: As far as I remember, it was decided in Berlin 2008 that an example implementation is made in UG. There was no mention of a grid factory (simply because the concept was only introduced on the Heidelberg meeting). The semantics of boundary segments were then only discussed in Berlin last year (and as far as I see it, parallel grids were completely ignored on this meeting).
@Robert: OK, there might be cases where this is nice.
@Martin: The 2008 meeting minutes (and my memory) indeed already mention a GridFactory. At the 2009 meeting it was explicitly stated that the parallel interface needs further research. So the missing parallel version is not a flaw of the decission but intended.
There was a decision in Berlin 2009. But since then there has been a lot of discussion on this and some further points came up, which (for me) even make the sequential interface questionable. The main problem is the internal generation of these boundary segments and the problem pops up in two places: load balancing and restart. This problem was also discussed in FS672.
It seems to me to be much simpler and clearer to add one boundary function to the grid which sort of is a discrete function on the boundary, e.g. has a method evaluate(intersection, localX). For element projections this could object could also have a method evaluate(entity,localX).Not all the boundary segments reside in this object (so not a lot is changed from the implementation already available in DUNE). There is no question of who owns these projections and load balancing and restart is a problem of the user who should be in position to handle it. Basically it boils down to the question, if boundary segments should be user data or something handles by the grid - some people found that question quite easy to answer for boundary ids why not for boundary projections?
The parametrization in the test case also scaled the domain. This caused the exception. Now the error is a little more usefull. IMHO this check should be removed since one might want to have (reference) coarse grids that do not interpolate the parametrized boundary.
Now the assertion in alu2dgridfactory.cc:298 fails if there are faces with and without BoundarySegment. See the modified test attached. Perhaps the factory should provide the identity as default globalProjection_ if none is given.
Attachments
-
I don't think I understand what you mean by scaling. ALUGrid and ALBERTA use the projection only to set the vertices created during refinement. In order to get some useful boundary approximation, this projection should map the vertices of the macro faces identically. And that's exactly what is checked.
I would have the following questions:
- What exactly do you mean by scaling? Can you give an example (maybe as DGF)?
- How does UG implement this?
If your parametrization does also move coarse grid vertices you can e.g. scale your geometry. Of course this is only valid if it is consistent across adjacent elements and if the coarse grid nodes are also moved. With ug this does currently work.
Since alugrid (and alberta?) does not move the coarse grid nodes this can not work (I just cheched this).
Indeed this is more like a transformation of the grid. Hence it's reasonable to forbid this for parametrizations.
mentioned in issue #753
