[MOAB-dev] commit/MOAB: 4 new changesets

[Grindeanu, Iulian R.]

Hi Tim and Vijay,
Thanks for the comments. I didn't see them until now, somehow.
________________________________________
From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Tim Tautges [timothy.tautges at cd-adapco.com]
Sent: Monday, June 30, 2014 8:55 AM
To: Vijay S. Mahadevan
Cc: moab-dev at mcs.anl.gov
Subject: Re: [MOAB-dev] commit/MOAB: 4 new changesets

On 06/30/2014 08:48 AM, Vijay S. Mahadevan wrote:
>> I think this name is too specific, and the allowed input is too constrained.
>> This example should be able to generate any structured mesh, not just a
>> large one.  And, there are functions that will compute the right partition
>> for you, so there shouldn't be any defaults for A/B/C.  Also, by convention
>> in structured meshes, the parameters are usually I/J/K.
>
> Agreed with everything there about the name, inputs and functionality.
> But this is just a first commit and it needs revisions based on
> comments. So its fine for now.

So what should be a proper name? 

So the example generates a model with A*B*C*M*N*K parts, on M*N*K processes. Each part has blockSize^3 hexas, and the sets get the parallel partition tag, so no mbpart is needed after that. Each process has AxBxC parts, in which the handle space is "contiguous"
(We still need to fix mbpart to run in parallel. Don't know yet how, I think the infrastructure is in place, or it was in place at some point)

I wanted to generate a big mesh file on a 
relatively small machine, which could be used later to test the reader on a big machine. 
So M, N, K, A, B, C have a slightly different meaning than I, J, K.
(The size of the mesh is AxMxblockSize in x direction, etc)


> including example addition. I think is_valid needs to be exposed since
> I've had instances when writing DMMoab when I wanted a sure fire way
> to check if something was garbage or a valid entity handle. Especially
> true for many asserts internal/external to MOAB in debug mode.
>

I don't think applications should be expected to check for valid handles, except under very specific cases (deletion
with either non-tracking sets or handle-type tags).  That should be made very clear in the comments/documentation for
this function.  If potential for error is that great, then put calls to is_valid under the hood on entry to functions
passing in handles and make them either asserts or compiled under #ifndef NDEBUG.

- tim

I think that if we allow on the interface to delete entities, we should allow the user to check if an entity is valid.
It is of course, his/her responsibility the moment it deletes entities.
In this particular case, I wanted to have a simple database, without edges and faces that get generated when we "resolve shared  entities"
That requires a fix in the ParallelComm that I am not comfortable making. (we have a flag , that gets ignored, or maybe I don't know how to use it)

>>
>> I think this is fixing the symptom, not the problem.  Deleting entities
>> should check with ParallelComm in parallel cases, and there should be a
>> ParallelComm function for a collective delete entities that takes care of
>> checking the sharers.
>>
>> - tim

Agreed that this should be a collective call, the moment we delete an entity that is shared everybody needs to be informed properly.

The correct fix for my problem is to understand what the  options "resolve_dim, shared_dim" are doing. I want to resolve just vertices, for the time being, I did not want the burden of extra sets / entities in the database.  Also, because I wanted more control over the global Id, I did not use ScdINterface. 

Thanks,
Iulian






> Vijay
>
> On Mon, Jun 30, 2014 at 8:25 AM, Tim Tautges
> <timothy.tautges at cd-adapco.com> wrote:
>> Several things bother me about this change:
>>>
>>> --- /dev/null
>>> +++ b/examples/GenLargeMesh.cpp
>>
>>
>> I think this name is too specific, and the allowed input is too constrained.
>> This example should be able to generate any structured mesh, not just a
>> large one.  And, there are functions that will compute the right partition
>> for you, so there shouldn't be any defaults for A/B/C.  Also, by convention
>> in structured meshes, the parameters are usually I/J/K.
>>
>>
>>> diff --git a/src/moab/Interface.hpp b/src/moab/Interface.hpp
>>
>>
>> IMO, any changes to Interface.hpp should at least go through pull requests,
>> and also should be discussed on the general list first.  I'm on the fence
>> about is_valid being a function on Interface, but only because we have sets
>> that don't track owners.  The reason you included it (to allow it being
>> called by ParallelComm) IMO isn't a valid one.
>>
>>
>>
>>
>>> --- a/src/parallel/ParallelComm.cpp
>>> +++ b/src/parallel/ParallelComm.cpp
>>> @@ -8789,7 +8789,22 @@ ErrorCode
>>> ParallelComm::settle_intersection_points(Range & edges, Range & shared
>>>
>>>      return MB_SUCCESS;
>>>      // end copy
>>> +}
>>> +ErrorCode ParallelComm::correct_shared_entities()
>>> +{
>>

>>
>> --
>> Timothy J. Tautges
>> Manager, Directed Meshing, CD-adapco
>> Phone: 608-354-1459
>> timothy.tautges at cd-adapco.com

--
Timothy J. Tautges
Manager, Directed Meshing, CD-adapco
Phone: 608-354-1459
timothy.tautges at cd-adapco.com