#672 GridFactory: "BoundarySegments" for Elements
Metadata
| Property | Value |
|---|---|
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Nov 30, 2009 10:55 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Jan 25, 2010 10:55 |
| Closed by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Closed at | Jan 25, 2010 10:55 |
| Closed in version | 2.1 |
| Resolution | Implemented |
| Comment |
Description
It was decided that the BoundarySegment class should be renamed and that it should be possible to have parametrized cells in the coarse grid.
Activity
I have a question regarding this ''segment'' functions: A valid argument against the original boundary ids was, that they are user data and should not be part of the grid. It seems to me that the same could be said for the BoundarySegments. The reason I am asking is that any restart facility would have to be able to write the boundary segments to disk - since they are part of the grid. Since they are virtual functions this does not seem to be possible? The same problem holds for load balancing again I have to be able to write and read a boundary segment. Why do we add segments to the grid factory instead of having them as user data accessible through the id sets or index sets or whatever the same as we are doing for boundary ids?
I think BoundarySegments are somewhere in between. Personally, I tend to think of them as part of the grid, but I can also understand the point that they are data. Either way, the restarting issue you describe is open. You need to be able to write BoundarySegments to disk and read them again. However it doesn't matter then whether they are grid or data. Reading/writing them is necessary either way.
Not quite true - the user knows the real type of the function, i.e., he can easily write the segment to disk and create it during restart with new and so on. How should a read method on a virtual base class work (write is of course easy but for read one needs to create the object with the correct type).
I think the problem with "who owns the these functions" shows that the segments are basically user data...
This is a classic problem in dynamic polymorphism, and there is a classic solution. You need a virtual method create() and/or a virtual method clone() in your hierarchy. The former replaces the default constructor, while the latter replaces the copy constructor. In fact, this is what the stuff in dune/common/interfaces.hh is good for.
cf. also, e.g., http://en.wikibooks.org/wiki/C%2B%2B_Programming/Classes/Polymorphism the section on virtual constructors.
Yes, you will need some sort of factory that allows to create the correct type of boundary segment depending on information read from a file. You are right in that what I wrote above only helps if you already have one object of the correct type. But again, you need the factory regardless of whether the grid or the outside application handles the boundary segments.
I would find it clearer to add one additional method to the GridFactory where a ''boundary segment container'' is added providing one method evaluate(en,x,y) for both element and boundary transformation. This container could for example then call boundarySeg[index(en)]->evaluate(x,y) giving exactly the same semantics as the strategy suggested by Oliver. But this is passed as const reference to the GridFactory so that no questions of ownership has to be addressed, handling grid reorganization is now user problem without having to provide an additional factory for boundary segment creation.
Comment by Andreas Dedner (dedner) - Friday, 18 December 2009, 10:33 GMT — Edit — Delete 672: for me at least the question is still open if these coordinate transformation functions (or ''boundary segments'') should not be handled like user data so that load balancing, checkpointing etc. can be more easily performed
- see discussion in 672 and the arguments against boundary ids. I know we voted on this so if all other developers are satisfied with the approach and see no further ground for discussion then lets add the method. But adding a method to an interface without one single implementation for proof of concepts, seems rather pointless to me and postponing to after 2.0 so that we can really see how the method works (in parallel for example) does not seem to introduce any disadvantage,
I admit that I never really thought about how parametrized boundaries should be handled in parallel. On the other hand nobody is proposing to add a new method. The method insertBoundarySegment is already there and implemented for UGGrid.
In any case I don't mind postponing this decision to after 2.0, though.
-
I think we don't have to support this feature in 2.0 already. The only grid that might use it is alberta as far as I know.
But I think we should already keep this feature in mind when it comes to naming of methods and classes. BoundarySegment does not really fir the parametrized elements.
