[MOAB-dev] Questions about Tags and Topology
Christopher Mueller
cmueller at asascience.com
Thu Feb 16 11:13:29 CST 2012
From: Tim Tautges <tautges at mcs.anl.gov<mailto:tautges at mcs.anl.gov>>
Date: Tue, 14 Feb 2012 09:30:53 -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>>, "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>>
Subject: Re: [MOAB-dev] Questions about Tags and Topology
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> <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> <mailto:cmueller at asascience.com>>
Cc: Iulian Grindeanu <iulian at mcs.anl.gov<mailto:iulian at mcs.anl.gov> <mailto:iulian at mcs.anl.gov>>, David Stuebe <DStuebe at asascience.com<mailto:DStuebe at asascience.com>
<mailto:DStuebe at asascience.com>>, Guy De Wardener <gdewardener at asascience.com<mailto:gdewardener at asascience.com> <mailto:gdewardener at asascience.com>>, don
brittain <don.brittain at instanteffects.com<mailto: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> <mailto:tautges at mcs.anl.gov>>
To: moab-dev at mcs.anl.gov<mailto: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>
<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>
<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> <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>
<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> <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> <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> <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.
That's no minor advantage! :)
>
>
> *
> * 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.
Excellent, I hadn't found that document yet – very useful
>
>
> *
>
> 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.
Yes, that confused me at first until I carefully read the documentation. For our purposes (at least right now), I think we'll pretty much always want ordered=False
>
>
> 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?
Ultimately, it would be great to be able to do this on a case-by-case basis (via PyTAPS). In the interim, is there any way of changing the AdjTable 'statically' (i.e. from a config file or even directly modifying a file) so that the table defaults to create all missing entities? At this point, it would be nice to always have all entities as opposed to only having the ones explicitly created (and vertices).
Thanks,
Chris
- 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> <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<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20120216/7806eacd/attachment-0001.htm>
More information about the moab-dev
mailing list