[MOAB-dev] Questions about Tags and Topology
Tim Tautges
tautges at mcs.anl.gov
Tue Feb 14 08:30:53 CST 2012
On 02/14/2012 07:59 AM, Christopher Mueller wrote:
> Hi Tim,
>
> Thank you very much for the information. I've added some comments inline.
>
> Best,
> Chris
>
> From: Tim Tautges <tautges at mcs.anl.gov <mailto:tautges at mcs.anl.gov>>
> Date: Mon, 13 Feb 2012 16:00:28 -0500
> To: Christopher Mueller <cmueller at asascience.com <mailto:cmueller at asascience.com>>
> Cc: Iulian Grindeanu <iulian at mcs.anl.gov <mailto:iulian at mcs.anl.gov>>, David Stuebe <DStuebe at asascience.com
> <mailto:DStuebe at asascience.com>>, Guy De Wardener <gdewardener at asascience.com <mailto:gdewardener at asascience.com>>, don
> brittain <don.brittain at instanteffects.com <mailto:don.brittain at instanteffects.com>>
> Subject: Re: [MOAB-dev] Questions about Tags and Topology
>
> [Sent the original just to MOAB-dev...]
>
> -------- Original Message --------
> Subject: Re: [MOAB-dev] Questions about Tags and Topology
> Date: Mon, 13 Feb 2012 14:59:15 -0600
> From: Tim Tautges <tautges at mcs.anl.gov <mailto:tautges at mcs.anl.gov>>
> To: moab-dev at mcs.anl.gov <mailto:moab-dev at mcs.anl.gov>
>
>
>
> On 02/13/2012 11:32 AM, Christopher Mueller wrote:
> > Hi Iulian,
> >
> > Thank you for the rapid response and great information. I have a couple of follow-up questions (inline).
> >
>
> A couple of my responses below too. But, first, great questions, you got into it pretty quickly.
>
> >
> >
> > From: Iulian Grindeanu <iulian at mcs.anl.gov <mailto:iulian at mcs.anl.gov> <mailto:iulian at mcs.anl.gov>
> <mailto:iulian at mcs.anl.gov>>>
> > Date: Sat, 11 Feb 2012 01:02:03 -0500
> > To: Christopher Mueller <cmueller at asascience.com <mailto:cmueller at asascience.com> <mailto:cmueller at asascience.com>
> <mailto:cmueller at asascience.com>>>
> > Cc: Guy De Wardener <gdewardener at asascience.com <mailto:gdewardener at asascience.com>
> <mailto:gdewardener at asascience.com> <mailto:gdewardener at asascience.com>>>, David Stuebe
> > <DStuebe at asascience.com <mailto:DStuebe at asascience.com> <mailto:DStuebe at asascience.com>
> <mailto:DStuebe at asascience.com>>>, don brittain <don.brittain at instanteffects.com
> <mailto:don.brittain at instanteffects.com>
> > <mailto:don.brittain at instanteffects.com> <mailto:don.brittain at instanteffects.com>>>, "moab-dev at mcs.anl.gov
> <mailto:moab-dev at mcs.anl.gov> <mailto:moab-dev at mcs.anl.gov> <mailto:moab-dev at mcs.anl.gov>>" <moab-dev at mcs.anl.gov
> <mailto:moab-dev at mcs.anl.gov>
> > <mailto:moab-dev at mcs.anl.gov> <mailto:moab-dev at mcs.anl.gov>>>
> > Subject: Re: [MOAB-dev] Questions about Tags and Topology
> >
> > Hello,
> > I will try to answer to some of those questions;
> >
> >
> ------------------------------------------------------------------------------------------------------------------------
> >
> > Hi Tim,
> >
> > I've had a good deal of success this week and have been able to represent a couple of our simpler datasets in
> > what seems to be a reasonable manner. I have also come up with a few questions.
> >
> > Tags:
> >
> > * DataTypes – from what I can see, tags do not support a few of the numpy datatypes, namely: float32, int16,
> > and int64. Is this a constraint of the PyTAPS wrapper or the underlying iMesh/MOAB infrastructure?
> >
> > itaps has a limited data type set; see MOAB/itaps/iBase.h
> > pytaps is closely related to itaps;
> >
> > some types can be "manufactured" out of byte type, but it is the user responsibility to interpret / convert
> > correctly (so interpret an int16 as a 2-byte value, etc). I am not sure if something like that is possible in
> > python/pytaps. It is for sure possible in c/c++
>
> We may be adding a float type soon, and I'm open to adding others if we can convince ourselves that it's worth it.
>
>
> Good to know. Given the response Jim provided it seems like we should be able to accommodate pretty much any data type,
> including custom ones. May be some efficiency to sticking with "native" types when possible though.
>
The advantage of using specific data types is mostly that you can read/write machine-independent binary files (i.e.
HDF5) and not be messed up by things like endian changes.
>
> >
> >
> > *
> > * Tags-of-tags – Is this possible? I've tried a couple of ways but can't seem to get it to go.
> >
> > tags can be set/get on anything that is an "EntityHandle" in moab. So anything that is an entity handle (node,
> > element, mesh set) can set and get tag values, using a tag handle.
> > I am not sure I understand the question. Would you need to set a tag value on a tag handle? That is not possible.
> >
> >
> > Unfortunately, it is the latter case that I was hoping for – the ability to set a tag value on a tag handle. For
> example:
> >
> > tag1=mesh.createTag("tag1",1,bytes)
> > tag2=mesh.createTag("tag2,1,bytes)
> > tag2[tag1]=value
> >
>
> I've long wondered about doing tags on tags, that would provide a way of putting attributes on tags, e.g. provenance
> data. I'll add you to the list of users that could potentially use that (the other use is for attributes coming from
> climate data files, so they're related to your uses).
>
>
> Thanks for the +1! The precise use case I had for doing this was for representing the attributes applicable to a given
> variable – so it definitely sounds like that fits into the use case you're already aware of.
>
Yeah. For other emerging conventions on various types of metadata, see the doc/metadata_info.pdf document, and
specifically the section on .nc files, lots of these are likely relevant to you guys too.
>
> >
> >
> > *
> >
> > Topology:
> >
> > * Is it possible to apply topology over entity sets? One way I've found for dealing with time is to have a
> > "temporal" EntitySet that has child EntitySets for each timestep. This seems to work well, but I can't find
> > a way of relating the various timesteps aside from the inherent indexing of the "temporal" EntitySet. I
> > hoped that it would be possible to do something like make a line_segment that related the timestep
> > EntitySets, but that didn't seem to work.
> >
> > maybe you can set a tag with the time value for each of the child EntitySets. I am not sure I understand what do you
> > mean by "line_segment".
> > Also, if set1 is a child of set2, it does not mean that the set2 is a parent of set1 (and viceversa) see the
> > difference between
> > add_parent_child and add_child_meshset, for example
> >
> > Another thing that can help:
> > you add child1 to set1, then add child2 to set1
> > When you ask for children of set1, you will always get them in order child1, child2. So maybe you can use that for a
> > natural ordering of your children ( EntitySets ).
> >
> >
> > This is the method I'm currently using and it works well as long as the relationship is a linear one (unfortunately,
> > this may not always be the case for us).
> > Do you know if it is possible to "insert" a child into an existing list of children? For example:
> >
> > set1_children=[c1,c2,c3,c4]
> > set.add(c2a,index=2)
> > set1_children=[c1,c2,c2a,c3,c4]
> >
>
> No, that's not currently possible. Another way to do this would be to implement a "next" tag, effectively implementing
> your own linked list between sets as tags. Note also that there are 2 kinds of sets in moab, list-type and set-type,
> and that only the list type preserves order under all conditions (the set-type sorts by handle and doesn't allow
> multiple inclusions of the same handle).
>
>
> OK – I was wondering how the sorting worked when a set is created "ordered=True". I'm using the "ordered=False" for all
> of my sets at this point.
>
Those names are very counter-intuitive, the ordered=true results in list-type sets, i.e. the order of members of the set
are *not* sorted, while the ordered=false sets are sorted.
>
>
> >
> >
> > Another question: Is the mesh changing in time? That is one reason you may want EntitySets changing in time. Or
> > maybe some solution uses different mesh elements at a given time
> >
> >
> > This is certainly a possibility, so having an entityset/time is valuable to us.
> >
> >
> >
> > *
> > * Edges from quadrilaterals: After building a set of quadrilateral entities from an array of vertices, I was
> > surprised that there were not edge entities generated as well. Is there a method for doing this? I realize I
> > could generate the edges from the vertex array (perhaps after some reworking), but it seems to me that it
> > might also be possible to get them from the quadrilaterals themselves.
> >
> >
> > this is the easiest question:)
> > you have to use the flag create_if_missing=true in a call like:
> > ErrorCode get_adjacencies(const EntityHandle *from_entities,
> > const int num_entities,
> > const int to_dimension,
> > const bool create_if_missing,
> > std::vector<EntityHandle>& adj_entities,
> > const int operation_type = Interface::INTERSECT) = 0;
> >
> > from_entities are your quads, to_dimension is 1 (edges), and you will get the edges in adj_entities vector.
> >
> >
> > This is great news! I tried applying the argument "create_if_missing" as a kwarg in a handful of the iMesh functions
> > exposed in PyTAPS (mesh.createEntArr, mesh.getEntArr, mesh.getEntAdj), but I kept getting a TypeError stating that
> > "'create_if_missing' is an invalid keyword argument for this function". Do you know if this functionality is available
> > from PyTAPS?
> >
>
> From iMesh/Pytaps, it's usually an all-or-nothing thing. If you're ok always having edges, then you can call the
> setAdjTable function, with the element with index 5 in the array set to one. That function takes an integer array
> argument that looks like a 4x4 table, indexed in column-major order, where the indices are [from_dim, to_dim], with
> diagonal elements used to indicate whether those entities should always be represented. So, the diagonal element
> pertaining to edges is at [1,1], which is at index 5 in a 0-based indexing.
>
>
> At this point, always having edges is not a problem at all. However I can't seem to modify the adjTable attribute (I
> believe Iulian found the same thing). I'm also not seeing a setAdjTable function. Am I missing something?
>
This has likely not been reflected in the pytaps implementation. Jim?
- tim
> In [1]: from itaps import iMesh
> In [2]: mesh=iMesh.Mesh()
> In [3]: mesh.adjTable
> Out[3]:
> array([[7, 4, 4, 1],
> [1, 0, 5, 5],
> [1, 5, 0, 5],
> [1, 5, 5, 7]], dtype=int32)
> In [4]: mesh.adjTable[1,1]
> Out[4]: 0
> In [5]: mesh.adjTable[1,1]=1
> In [6]: mesh.adjTable[1,1]
> Out[6]: 0
> In [7]: import numpy
> In [8]: mesh.adjTable=numpy.array([[7,4,4,1],[1,1,5,5],[1,5,0,5],[1,5,5,7]],dtype='int32')
> ---------------------------------------------------------------------------
> AttributeError Traceback (most recent call last)
> /Users/cmueller/Development/OOI/Dev/datamodel/prototypes/<ipython-input-8-5671b50e588e> in <module>()
> ----> 1 mesh.adjTable=numpy.array([[7,4,4,1],[1,1,5,5],[1,5,0,5],[1,5,5,7]],dtype='int32')
>
> AttributeError: attribute 'adjTable' of 'itaps.iMesh.Mesh' objects is not writable
>
>
>
>
>
>
> - tim
>
> >
> >
> > Thanks in advance,
> > Chris
> >
> > Hope this helps,
> > Iulian
> >
> >
> > Thanks,
> > Chris
>
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
> steadfast, because he trusts in you." Isaiah 26:3
>
> Tim Tautges Argonne National Laboratory
> (tautges at mcs.anl.gov <mailto:tautges at mcs.anl.gov>) (telecommuting from UW-Madison)
> phone (gvoice): (608) 354-1459 1500 Engineering Dr.
> fax: (608) 263-4499 Madison, WI 53706
>
>
--
================================================================
"You will keep in perfect peace him whose mind is
steadfast, because he trusts in you." Isaiah 26:3
Tim Tautges Argonne National Laboratory
(tautges at mcs.anl.gov) (telecommuting from UW-Madison)
phone (gvoice): (608) 354-1459 1500 Engineering Dr.
fax: (608) 263-4499 Madison, WI 53706
More information about the moab-dev
mailing list