[MOAB-dev] Attaching a C++ class to Mesh entities?

[Anthony Scopatz]

On Fri, Oct 11, 2013 at 2:07 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Anthony Scopatz <scopatz at gmail.com> writes:
> > Yes this is exactly what we want to do because the species that live on
> the
> > mesh will change as a function of time. There are ~4000 known nuclides, a
> > cell may start with 2 of them and may grow to 400 of them...or not.  Hard
> > coding an array of approved species is one of the great failings of many
> NE
> > codes, in my opinion.
>
> So note that if on each time step/iteration you change the length of the
> species, you'll typically be reallocating.  It is in fact very fast to
> create a single new array of the size you need and then copy over
> (expanding some cells, contacting others, etc).  But if you prefer
> std::map, you're welcome to use that too.  (Use a custom allocator if
> that becomes a performance issue, which it probably won't from the
> sounds of your traversal.  std::map is pretty slow, but you can replace
> it with a sorted array or hash table.)
>

std::map is super slow.  I have thought about changing it many times,
but it has never been the limiting factor so I have yet to actually do
anything
about it.


>
> >> > 2. Keep an external dictionary / map which is keyed by the entity and
> >> > valued by Material objects
> >>
> >> Arrays work well for this.
> >>
> >
> > Wouldn't using arrays assume some nominal ordering of the cells?
>
> Tag the cells you want to use with a sequential integer index, or even
> just use the cell index from your cell iterator if you never need
> neighbor access.
>

 That is a good idea.  I like that and will use it if the GLOBAL_ID doesn't
pan out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20131011/859e758c/attachment-0001.html>