February 2012 - moab-dev - mailman3.cels.anl.gov

buildbot failure in moab-par: failed compile test
by moab-dev＠mcs.anl.gov 19 Feb '12

19 Feb '12

1 0

buildbot failure in moab-par: failed compile test
by moab-dev＠mcs.anl.gov 18 Feb '12

18 Feb '12

1 0

r5407 - MOAB/trunk/itaps/imesh
by jvporter＠wisc.edu 17 Feb '12

17 Feb '12

Author: jvporter Date: 2012-02-17 17:50:17 -0600 (Fri, 17 Feb 2012) New Revision: 5407 Modified: MOAB/trunk/itaps/imesh/MBIter.hpp Log: Add a step_iterator helper function to improve efficiency of the iMesh_stepIter function Modified: MOAB/trunk/itaps/imesh/MBIter.hpp =================================================================== --- MOAB/trunk/itaps/imesh/MBIter.hpp 2012-02-17 21:17:41 UTC (rev 5406) +++ MOAB/trunk/itaps/imesh/MBIter.hpp 2012-02-17 23:50:17 UTC (rev 5407) @@ -54,13 +54,60 @@ } }; +// step_iterator will safely step forward N steps in a iterator. We specialize +// for random-access iterators (vectors and Ranges) so that they perform better. +template <typename T> +ErrorCode step_iterator(T &curr, const T &end, int num_steps, bool &at_end) +{ + if (0 > num_steps) return MB_FAILURE; + + while (num_steps && curr != end) { + num_steps--; + curr++; + } + at_end = (curr == end); + return MB_SUCCESS; +} + +template <typename T> +ErrorCode step_iterator(typename std::vector<T>::const_iterator &curr, + const typename std::vector<T>::const_iterator &end, + int num_steps, bool &at_end) +{ + if (0 > num_steps) return MB_FAILURE; + + assert(curr <= end); // Sanity check + at_end = (end - curr <= num_steps); + + if (at_end) + curr = end; + else + curr += num_steps; + return MB_SUCCESS; +} + +ErrorCode step_iterator(Range::const_iterator &curr, + const Range::const_iterator &end, int num_steps, + bool &at_end) +{ + if (0 > num_steps) return MB_FAILURE; + + at_end = (end - curr <= num_steps); + + if (at_end) + curr = end;

1 0

r5406 - MOAB/trunk/itaps/imesh
by sjackson＠cae.wisc.edu 17 Feb '12

17 Feb '12

Author: sjackson Date: 2012-02-17 15:17:41 -0600 (Fri, 17 Feb 2012) New Revision: 5406 Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp MOAB/trunk/itaps/imesh/iMesh_extensions.h Log: Simplify the behavior of iMesh_createStructureMesh Change the behavior of the set_handle parameter so that it is either set equal to the underly ScdBox's entity set, or else has that set added to it. Vertices and mesh elements are no longer added directly to the set_handle set under any circumstance. Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp =================================================================== --- MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2012-02-17 18:58:21 UTC (rev 5405) +++ MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2012-02-17 21:17:41 UTC (rev 5406) @@ -3225,16 +3225,15 @@ if (set_handle) { if (!(*set_handle)) { - // make a new set - EntityHandle tmp_set; - rval = MOABI->create_meshset(MESHSET_SET, tmp_set); - CHKERR(rval, "Couldn't create entity set."); - *set_handle = (iBase_EntitySetHandle)tmp_set; + // return the new ScdBox's set + *set_handle = reinterpret_cast<iBase_EntitySetHandle>(scd_box->box_set()); } - - // add box set and new vertices, elements to the file set - rval = MOABI->add_entities(ENTITY_HANDLE(*set_handle), tmp_range); - CHKERR(rval, "Couldn't add new vertices to file set."); + else{ + // add the new ScdBox's set to the given file set + EntityHandle s = scd_box->box_set(); + rval = MOABI->add_entities(ENTITY_HANDLE(*set_handle), &s, 1 ); + CHKERR(rval, "Couldn't add box set to file set."); + } } // get a ptr to global id memory Modified: MOAB/trunk/itaps/imesh/iMesh_extensions.h =================================================================== --- MOAB/trunk/itaps/imesh/iMesh_extensions.h 2012-02-17 18:58:21 UTC (rev 5405) +++ MOAB/trunk/itaps/imesh/iMesh_extensions.h 2012-02-17 21:17:41 UTC (rev 5406) @@ -296,7 +296,8 @@ int elem_gids, /**< [in] If non-zero, assigns global ids to elements, according to global parameterization. */ iBase_EntitySetHandle* set_handle, - /**< [inout] Entity set handle in which to put box and vertices/elements, NULL if not desired, *NULL if function should create one. */ + /**< [inout] A set to which the underlying ScdBox set will be added. NULL if not desired. + * If *NULL, will be set directly to the underlying ScdBox's set. */ int *err /**< [out] Error flag. */ );

1 0

Fwd: Re: iMesh / ScdMesh questions
by Tim Tautges 17 Feb '12

17 Feb '12

[Forwarding to MOAB-dev since it might be of general interest...] -------- Original Message -------- Subject: Re: iMesh / ScdMesh questions Date: Fri, 17 Feb 2012 13:36:55 -0600 From: Tim Tautges <tautges(a)mcs.anl.gov> To: Steve Jackson <stjackson(a)wisc.edu> CC: James Porter <jvporter(a)wisc.edu> It's that way because sometimes the underlying function is called from a reader, which itself was passed a set by the application. In some cases it could be that that set already contained other structured sets, or was a collection of data not all of which was structured. The biggest problem with the behavior now, going by your summary, is that in case 3 below, both sets get the vertices and elements. I think a better behavior would be to put them in only the set E. Then, you could get the behavior you prefer, i.e. one set with just the vertices and elements and marked as a structured set (case 2), while applications could also get back the equivalent of file sets that possibly contained subsets representing structured boxes. Could you live with that? - tim On 02/17/2012 10:34 AM, Steve Jackson wrote: > Hi Tim, > > I am curious about the the behavior of the structured mesh code and its itaps extension. > > One of the parameters to iMesh_createStructuredMesh() is an entity handle pointer called set_handle. The parameter is treated three different ways: > > 1) If NULL, ignore. > 2) If a pointer to NULL, allocate a new EntitySet and add all the contents of the created ScdMesh to that set. > 3) If a pointer to non-NULL, add all the contents to the pointed-to EntitySet. > > "All the contents" means "the vertices, the hexahedra, and the entity set E representing the ScdBox." > > That last entity set E is interesting because it is the set on which the BOX_DIMS and BOX_PERIODIC tags are set. This means that an itaps client who wants reliable access to the BOX_DIMS information has to do the following: > > 1) Pass in a non-NULL set_handle to iMesh_createStructuredMesh() > 2) Look up the lone entity set E contained within set_handle > 3) Access tag values on E > > It's a possible source of confusion because set_handle and E contain identical vertices and elements. They are different in two ways: > > a) set_handle contains E > b) E has ScdBox tag data set on it > > My instinct says that this is a needless complexity. The set that a user is likely to want is E, rather than a set that contains E as well as all of E's geometry. > > If I were to propose an alternative, it would be to treat the set_handle parameter to iMesh_createStructuredMesh() as follows: > > 1) If NULL, ignore. > 2) If non-NULL, set equal to E, the entity set that represents the new ScdBox. > > The if a user wants a new entity set containing the ScdBox's geometry, they can create one separately and copy the contents of E into it. I'm willing to make such a change if it seems safe to you. > ~S > -- ================================================================ "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(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

3 2

Re: [MOAB-dev] Questions about Tags and Topology
by Tim Tautges 16 Feb '12

16 Feb '12

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(a)mcs.anl.gov <mailto:[email protected]>> > Date: Mon, 13 Feb 2012 16:00:28 -0500 > To: Christopher Mueller <cmueller(a)asascience.com <mailto:[email protected]>> > Cc: Iulian Grindeanu <iulian(a)mcs.anl.gov <mailto:[email protected]>>, David Stuebe <DStuebe(a)asascience.com > <mailto:[email protected]>>, Guy De Wardener <gdewardener(a)asascience.com <mailto:[email protected]>>, don > brittain <don.brittain(a)instanteffects.com <mailto:[email protected]>> > 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(a)mcs.anl.gov <mailto:[email protected]>> > To: moab-dev(a)mcs.anl.gov <mailto:[email protected]> > > > > 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(a)mcs.anl.gov <mailto:[email protected]> <mailto:[email protected]> > <mailto:[email protected]>>> > > Date: Sat, 11 Feb 2012 01:02:03 -0500 > > To: Christopher Mueller <cmueller(a)asascience.com <mailto:[email protected]> <mailto:[email protected]> > <mailto:[email protected]>>> > > Cc: Guy De Wardener <gdewardener(a)asascience.com <mailto:[email protected]> > <mailto:[email protected]> <mailto:[email protected]>>>, David Stuebe > > <DStuebe(a)asascience.com <mailto:[email protected]> <mailto:[email protected]> > <mailto:[email protected]>>>, don brittain <don.brittain(a)instanteffects.com > <mailto:[email protected]> > > <mailto:[email protected]> <mailto:[email protected]>>>, "moab-dev(a)mcs.anl.gov > <mailto:[email protected]> <mailto:[email protected]> <mailto:[email protected]>>" <moab-dev(a)mcs.anl.gov > <mailto:[email protected]> > > <mailto:[email protected]> <mailto:[email protected]>>> > > 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(a)mcs.anl.gov <mailto:[email protected]>) (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(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

4 11

MOAB Concurrency
by Christopher Mueller 16 Feb '12

16 Feb '12

Hi All, I'm trying to get a little clarification on exactly how concurrency works with MOAB. When one process is reading a mesh (or more likely, data on a mesh) from a file and another process attempts to write to that file, what happens? Does the writer get blocked until the reader is through? Can the file be modified by the writer while a reader has an in-memory representation of the file? Is there a mechanism for the reader to know if the underlying file has changed (is this what <https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxyge…> iMesh_areEHValid<https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxyge…> does)? Does the same answer apply (with roles reversed) if the reader process starts after the writer process? Are there strategies in place for dealing with these situations? Thanks in advance, Chris

2 2

Questions about Tags and Topology
by Christopher Mueller 13 Feb '12

13 Feb '12

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? * Tags-of-tags – Is this possible? I've tried a couple of ways but can't seem to get it to go. 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. * 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. Thanks in advance, Chris

4 7

r5390 - MOAB/trunk/tools/dagmc
by sjackson＠cae.wisc.edu 10 Feb '12

10 Feb '12

Author: sjackson Date: 2012-02-10 15:46:10 -0600 (Fri, 10 Feb 2012) New Revision: 5390 Modified: MOAB/trunk/tools/dagmc/DagMC.cpp Log: Work around an issue in DagMC::entity_by_id() This function did not behave as expected on reloaded geometries from older versions of DagMC. Modified: MOAB/trunk/tools/dagmc/DagMC.cpp =================================================================== --- MOAB/trunk/tools/dagmc/DagMC.cpp 2012-02-10 18:30:46 UTC (rev 5389) +++ MOAB/trunk/tools/dagmc/DagMC.cpp 2012-02-10 21:46:10 UTC (rev 5390) @@ -1404,8 +1404,19 @@ Range results; rval = MBI->get_entities_by_type_and_tag( 0, MBENTITYSET, tags, vals, 2, results ); - if (MB_SUCCESS != rval || results.empty()) - return 0; + + if ( MB_SUCCESS != rval ) + return 0; + + if ( results.empty() ){ + // old versions of dagmc did not set tags correctly on the implicit complement 'volume', + // causing it to not be found by the call above. This check allows this function to work + // correctly, even on reloaded files from older versions. + if( dimension == 3 && get_entity_id(impl_compl_handle) == id ) + return impl_compl_handle; + else + return 0; + } return results.front(); }

1 0

r5381 - in MOAB/trunk/src/parallel: . moab
by hongjun＠mcs.anl.gov 07 Feb '12

07 Feb '12

Author: hongjun Date: 2012-02-07 14:53:47 -0600 (Tue, 07 Feb 2012) New Revision: 5381 Modified: MOAB/trunk/src/parallel/ParallelComm.cpp MOAB/trunk/src/parallel/moab/ParallelComm.hpp Log: o "send_entities", "recv_entities" and "post_irecv" functions are added o They are used for send and recv meshes separately and can do mesh generation during communication o passes make check Modified: MOAB/trunk/src/parallel/ParallelComm.cpp =================================================================== --- MOAB/trunk/src/parallel/ParallelComm.cpp 2012-02-07 18:26:59 UTC (rev 5380) +++ MOAB/trunk/src/parallel/ParallelComm.cpp 2012-02-07 20:53:47 UTC (rev 5381) @@ -701,6 +701,125 @@ #endif } +ErrorCode ParallelComm::send_entities(std::vector<unsigned int>& send_procs, + std::vector<Range*>& send_ents, + int& incoming1, int& incoming2, + const bool store_remote_handles) +{ +#ifdef USE_MPE + if (myDebug->get_verbosity() == 2) { + MPE_Log_event(OWNED_START, procConfig.proc_rank(), "Starting send entities."); + } +#endif + myDebug->tprintf(1, "Entering send_entities\n"); + if (myDebug->get_verbosity() == 4) { + msgs.clear(); + msgs.reserve(MAX_SHARING_PROCS); + } + + unsigned int i; + int ind, success; + ErrorCode result = MB_SUCCESS; + + // set buffProcs with communicating procs + unsigned int n_proc = send_procs.size(); + for (i = 0; i < n_proc; i++) { + ind = get_buffers(send_procs[i]); + result = add_verts(*send_ents[i]); + RRA("Couldn't add verts."); + + // filter out entities already shared with destination + Range tmp_range; + result = filter_pstatus(*send_ents[i], PSTATUS_SHARED, PSTATUS_AND, + buffProcs[ind], &tmp_range); + RRA("Couldn't filter on owner."); + if (!tmp_range.empty()) { + *send_ents[i] = subtract(*send_ents[i], tmp_range); + } + } + + //=========================================== + // get entities to be sent to neighbors + // need to get procs each entity is sent to + //=========================================== + Range allsent, tmp_range; + int dum_ack_buff;

1 0