dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Sep 06, 2011 at 08:45:18PM +0100, Garth N. Wells wrote:
> On 6 September 2011 19:16, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Tue, Sep 06, 2011 at 07:14:01PM +0100, Garth N. Wells wrote:
> >> On 6 September 2011 19:04, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > On Tue, Sep 06, 2011 at 05:45:33PM +0100, Garth N. Wells wrote:
> >> >> On 6 September 2011 17:31, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> >> >> > On Monday September 5 2011 00:09:58 Anders Logg wrote:
> >> >> >> On Sun, Sep 04, 2011 at 11:23:04PM -0700, Johan Hake wrote:
> >> >> >> > On Friday September 2 2011 23:19:22 Anders Logg wrote:
> >> >> >> > > On Fri, Sep 02, 2011 at 02:35:57PM -0700, Johan Hake wrote:
> >> >> >> > > > What is the different between a MeshMarker and a MeshFunction? Is
> >> >> >> > > > MeshMarker a MeshFunction but instead of storing the values in line
> >> >> >> > > > with its global entity index it stores it wrt the global cell entity
> >> >> >> > > > index together with its local entity index?
> >> >> >> > >
> >> >> >> > > Yes, that and values don't need to be stored on the entire mesh, only
> >> >> >> > > for a subset, so you can mark just 3 facets without needing to store
> >> >> >> > > markers for a million facets.
> >> >> >> >
> >> >> >> > ok, I will see what I can do.
> >> >> >>
> >> >> >> Thanks!
> >> >> >>
> >> >> >> > > Copy paste from the MeshMarker docstring:
> >> >> >> > >   /// The MeshMarkers class can be used to store data associated with
> >> >> >> > >   /// a subset of the entities of a mesh of a given topological
> >> >> >> > >   /// dimension. It differs from the MeshFunction class in two ways.
> >> >> >> > >   /// First, data does not need to be associated with all entities
> >> >> >> > >   /// (only a subset). Second, data is associated with entities
> >> >> >> > >   /// through the corresponding cell index and local entity number
> >> >> >> > >   /// (relative to the cell), not by global entity index, which means
> >> >> >> > >   /// that data may be stored robustly to file.
> >> >> >> > >
> >> >> >> > > > Also, will this take over for the way we use MeshFunctions in the
> >> >> >> > > > assembler, or will a MeshFunction be generated by a MeshMarker before
> >> >> >> > > > assemble gets called?
> >> >> >> > >
> >> >> >> > > I think we will do that as a first step (convert from MeshMarker to
> >> >> >> > > MeshFunction) since then we don't need to touch the assembler. Then
> >> >> >> > > later we can think about using MeshMarkers directly.
> >> >> >> >
> >> >> >> > Ok.
> >> >> >> >
> >> >> >> > > > I think I also get confused with the naming here. If my explaination
> >> >> >> > > > of what MeshMarker is doing is correct, a MeshMarker and a
> >> >> >> > > > MeshFunction are essentially doing the same thing. What differs is
> >> >> >> > > > the way the data is stored. This is not reflected in the naming of
> >> >> >> > > > the classes
> >> >> >> > >
> >> >> >> > > It was the best I could come up with. Feel free to suggest something
> >> >> >> > > else. SubsetMeshFunction would also be confusing since it's not really
> >> >> >> > > a MeshFunction.
> >> >> >> > >
> >> >> >> > > Either way, I expect the MeshMarkers class to be used mostly
> >> >> >> > > internally by the MeshDomains class.
> >> >> >> >
> >> >> >> > Ok.
> >> >> >> >
> >> >> >> > Not sure these are better, but they might reflect the difference between
> >> >> >> > this guy and a MeshFunction in a slightly more intuitive way.
> >> >> >> >
> >> >> >> >   MeshEntityFunction, LocalMeshEntityFunction, LocalMeshFunction,
> >> >> >> >   SubMeshFunction
> >> >> >>
> >> >> >> I'm not sure those are much better, and I don't think it would be
> >> >> >> correct to call them something containing "Function" since they are
> >> >> >> not really functions. With a MeshFunction, one can input x (a mesh
> >> >> >> entity) and get y = f(x) (the value of the MeshFunction at that
> >> >> >> entity). That's not possible with MeshMarkers; they are just a
> >> >> >> collection of markers, not really a function since the value is only
> >> >> >> defined on a subset and one would need to loop through the list of
> >> >> >> values to get the value at any entity where the value is actually
> >> >> >> defined.
> >> >> >
> >> >> > What with MeshValueCollection? As it is a templated class I do not think
> >> >> > Marker is an appropriated name.
> >> >>
> >> >> Agree.
> >> >>
> >> >> > 'Collection' says that the class is not
> >> >> > defined over the whole Mesh.
> >> >
> >> > I don't see what the templating has to do with the name "markers" but
> >> > MeshValueCollection sounds good.
> >> >
> >>
> >> Because 'markers' leads one to believe that it's a boolean or integer.
> >
> > ok.
> >
> >> >> > Two questions:
> >> >> >
> >> >> > How can the following code work:
> >> >> >
> >> >> >      // Get marker data
> >> >> >      const std::vector<uint>& marker = _markers[i];
> >> >> >      const uint cell_index   = marker[0];
> >> >> >      const uint local_entity = marker[1];
> >> >> >      const T marker_value    = marker[2];
> >> >> >
> >> >> > when _markers is declared as:
> >> >> >
> >> >> >    // The markers
> >> >> >    std::vector<std::pair<std::pair<uint, uint>, T> > _markers;
> >> >
> >> > The above code doesn't work. I suspect the code hasn't yet been
> >> > instantiated so it wasn't detected by the compiler.
> >> >
> >> > The markers need to be accessed as follows (from XMLMeshMarkers.h):
> >> >
> >> >  for (uint i = 0; i < mesh_markers.size(); ++i)
> >> >  {
> >> >    pugi::xml_node entity_node = mf_node.append_child("marker");
> >> >    const std::pair<std::pair<uint, uint>, T>& marker =
> >> >      mesh_markers.get_marker(i);
> >> >    entity_node.append_attribute("cell_index") = marker.first.first;
> >> >    entity_node.append_attribute("local_entity") = marker.first.second;
> >> >    entity_node.append_attribute("marker_value") = marker.second;
> >> >  }
> >> >
> >> >> The above also permits multiple entries. Perhaps we want
> >> >>
> >> >>     boost::unordered_map<std::pair<std::pair<uint, uint>, T> > _markers;
> >> >
> >> > Yes, maybe but I'm not sure what the cost would be for the lookup on
> >> > each cell during assembly.
> >> >
> >>
> >> No need for a look up, just iterate over the map.
> >
> > Then why do we need a map?
> >
>
> Because the object maps a pair to a value. A std::vector would allow
> multiple entries with the same (uint, uint) pair, which is ambiguous.
> If we want, for example, to apply a bc based on a 'marker' we can
> iterate over the markers and get the value, and then depending on the
> marker do something.

Sounds good, plus we can consider using it during assembly without
converting to a MeshFunction.

> >> >> > What is the logic behind:
> >> >> >
> >> >> >    // Set all value of mesh function to maximum value (not all will
> >> >> >    // be set) by markers below
> >> >> >    mesh_function.set_all(maxval);
> >> >> >
> >> >> > Isn't it more natural to initiate the values to zero? Also it makes no sense
> >> >> > in conjunction with boundary markers. Then all boundary faces gets marked with
> >> >> > the largest marker value. I cannot see how that could be correct.
> >> >> >
> >> >>
> >> >> I don't get ' mesh_function.set_all(maxval);' or the code comment.
> >> >
> >> > The point is that one should be able to define a form with domains say
> >> > dx(0), dx(1) and dx(2) and then have a mesh file that marks a subset
> >> > of the cells with '0', '1' and '2'.
> >> >
> >> > Then the conversion to MeshFunction inserts '3' for all other
> >> > (unmarked) cells. This allows a user to specify only the interesting
> >> > cells and no need to mark the rest with -1 or None or similar.
> >> >
> >>
> >> Could you be precise about which class functions belong to and the
> >> argument types for the above point?
> >
> > I don't understand the question.
> >
>
> Function signature.

There is really no signature for that. This would happen when the
data stored in MeshValueCollection is converted to a MeshFunction.

--
Anders


> Garth
>
> >
> >
> >> Garth
> >>
> >> >> >> So MeshMarkers may not be that bad. I'm starting to get used to
> >> >> >> it... :-)
> >> >> >
> >> >> > That's what worries me :)
> >> >> >
> >> >>
> >> >> Me too (worried, that is).
> >> >
> >> > Don't worry.
> >> >
> >> >
> >