[MOAB-dev] Closing/opening moab instances

Tim Tautges (ANL) tautges at mcs.anl.gov
Mon Jan 20 15:47:02 CST 2014 


On 01/20/2014 03:44 PM, Patrick Shriwise wrote:
> On 01/20/2014 02:58 PM, Tim Tautges (ANL) wrote:
>>
>>
>> On 01/20/2014 02:10 PM, Paul Wilson wrote:
>>> Hi Tim,
>>>
>>> On 01/20/2014 01:43 PM, Tim Tautges (ANL) wrote:
>>>> Hmm, then I'd add a ticket for MOAB that requests this entity set get populated appropriately. Are you sure this isn't
>>>> being handled properly outside CGM, on the MOAB side?
>>>
>>> I think it depends a little what you mean by handled properly - perhaps a slightly more detailed response where I try to
>>> be more careful with terminology.
>>>
>>> In a call to ReadCGM::load_file() there is a MOAB entity set available for correctly grouping the MOAB entities that are
>>> generated during that call. However, during ReadCGM::load_file(), there is a call to CubitCompat_import_solid_model()
>>> that loads a solid model into the CGM singleton instance. Thereafter, there is a call to
>>> GeometryQueryTool::ref_entity_list() for all the RefEntities of a given dimension.
>>>
>>> If the geometry is explicitly cleared/deleted before a call to ReadCGM::load_file(), then those calls to
>>> GeometryQueryTool::ref_entity_list() will only return the RefEntities that are associated with the most recent
>>> CubitCompat_import_solid_model(), and associate them correctly with the MOAB file entity set.
>>>
>>> If the geometry is NOT cleared/deleted before a call to ReadCGM::load_file(), then those calls to
>>> GeometryQueryTool::ref_entity_list() will return ALL the RefEntities that are associated with ALL PREVIOUS
>>> CubitCompat_import_solid_model(), and associate them ALL with the MOAB file entity set.
>>>
>>> I don't think it's a problem on the MOAB side, per se. I think it's a problem with the expected behavior of
>>> ReadCGM::load_file() over multiple subsequent calls. I don't think this behavior has been explicitly defined before and
>>> the kind of tests that Patrick was writing exposed this for the first time.
>>>
>>
>> Ok, right.
>>
>> First, I think it would be good to enable both behaviors (keep the model or delete it), because I can envision
>> plausible use cases for both (and, since we eventually want some of this code to be shared or move to MeshKit,
>> obviously we'll need it there).
>>
>> Second, I guess if the model in CGM is not deleted, then either ReadCGM needs to keep a reference to it and filter out
>> those from subsequent reads, or we need a tag pointing from the MOAB entity sets to their CGM counterparts (sounds
>> like iRel/Lasso, no?).
>>
>> - tim
>>
>
> I agree that both behaviors should be kept available and (thinking of this from my current perspective) that a test
> should be written to make sure this is working properly. As far as keeping connection between corresponding MOAB
> entities and CGM entities goes, is the only purpose of maintaining these connections to filter out the pre-existing
> geometry in CGM?

Yes.

  If so, would it be better to make the load_file more modular and allow it to load multiple files into
> the instance or simply keep track of file names (either on the MOAB side or the CGM side) already loaded into the CGM
> instance and simply don't load them again if they are called?
>

Depends on whether you can assume the ReadCGM object will be persistent or not.  Currently I don't think they persist if 
they're read in separate load_file calls.

- tim

> -Patrick
>
>>> It is difficult to imagine a case where the user would want the current behavior. The most logical default behavior to
>>> me is to clear the solid model before each CubitCompat_import_solid_model(), and allow an option to prevent this.
>>>
>>> Does this make sense?
>>>
>>> Paul
>>>
>>>
>>>>
>>>> - tim
>>>>
>>>> On 01/18/2014 07:40 AM, Paul Wilson wrote:
>>>>>
>>>>> On Jan 17, 2014, at 20:48, "Tautges, Timothy J." <tautges at mcs.anl.gov <mailto:tautges at mcs.anl.gov>> wrote:
>>>>>
>>>>>> I think it should be optional too. Patrick, each separate read should be passing in an entity set anyway, so either
>>>>>> way you should be able to tell what resulted from a given read.
>>>>>
>>>>> This is only true if the geom gets cleared each time because ReadCGM calls import_solid_model w/o any notion of a
>>>>> set to
>>>>> hold it separate. ReadCGM then queries the geom for all RefEntities of a given dimension. Thus, even with a distinct
>>>>> entity set on the MOAB side, it will contain all the entities from prior reads if the geom doesn't get cleared.
>>>>>
>>>>> Paul
>>>>>
>>>>> -- --
>>>>> Professor, Nuclear Engineering
>>>>> Faculty Director, Advanced Computing Infrastructure
>>>>> UW-Madison
>>>>> wilsonp at engr.wisc.edu <mailto:wilsonp at engr.wisc.edu>, 608.263.0807
>>>>> Sent from my iPhone
>>>>>
>>>>>>
>>>>>> And, dated reply, but you can't create/destroy multiple cgm instances in the same session, due to the singletons and
>>>>>> some other things in cgm.
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>> Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone
>>>>>>
>>>>>>
>>>>>> -------- Original message --------
>>>>>> From: Paul Wilson
>>>>>> Date:01/17/2014 4:33 PM (GMT-06:00)
>>>>>> To: "Grindeanu, Iulian R."
>>>>>> Cc: Patrick Shriwise ,"Tautges, Timothy J." ,moab-dev at mcs.anl.gov <mailto:moab-dev at mcs.anl.gov>
>>>>>> Subject: Re: [MOAB-dev] Closing/opening moab instances
>>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> Actually, I don't think we should always delete_ geometry after ReadCGM. There is theoretically a DAGMC capability to
>>>>>> use the geometry for some ray-firing calls that would require the geometry to be loaded. (We need to add tests for
>>>>>> this.)
>>>>>>
>>>>>> We could add options to ReadCGM:
>>>>>> • on/off delete on entering ReadCGM()
>>>>>> • on/off delete on exiting ReadCGM()
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> -- --
>>>>>> Professor, Nuclear Engineering
>>>>>> Faculty Director, Advanced Computing Infrastructure
>>>>>> UW-Madison
>>>>>> wilsonp at engr.wisc.edu <mailto:wilsonp at engr.wisc.edu>, 608.263.0807
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> > On Jan 17, 2014, at 16:15, "Grindeanu, Iulian R." <iulian at mcs.anl.gov <mailto:iulian at mcs.anl.gov>> wrote:
>>>>>> >
>>>>>> > I think we should call "delete_geometry" on cgm instance after read_cgm finishes its job.
>>>>>> > I cannot think of any instance in which we would want the entities persistent.
>>>>>> > maybe Rajeev has though issues when coregen-type calls are made in meshkit. I know that there multiple files
>>>>>> > are loaded; I assume that these files are sat/occ files, and are read as geometry, not converted to mesh by
>>>>>> ReadCGM. Tim or Rajeev could confirm if calling "delete_geometry" is a problem or not;
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Iulian
>>>>>> > ________________________________________
>>>>>> > From:moab-dev-bounces at mcs.anl.gov <mailto:moab-dev-bounces at mcs.anl.gov> [moab-dev-bounces at mcs.anl.gov
>>>>>> <mailto:moab-dev-bounces at mcs.anl.gov>] on behalf of Patrick Shriwise [shriwise at wisc.edu <mailto:shriwise at wisc.edu>]
>>>>>> > Sent: Friday, January 17, 2014 4:02 PM
>>>>>> > To: Tautges, Timothy J.
>>>>>> > Cc:moab-dev at mcs.anl.gov <mailto:moab-dev at mcs.anl.gov>
>>>>>> > Subject: Re: [MOAB-dev] Closing/opening moab instances
>>>>>> >
>>>>>> >> On 01/14/2014 09:46 AM, Patrick Shriwise wrote:
>>>>>> >>> On 01/09/2014 12:43 PM, Tim Tautges (ANL) wrote:
>>>>>> >>> Either declare the Core instance in a local variable, e.g. as in the
>>>>>> >>> test/MBTest.cpp test (mb_vertex_coordinate_test function and the ones
>>>>>> >>> following), or use Interface::delete_mesh. I'd recommend the former,
>>>>>> >>> as that gives you a clean instance.
>>>>>> >>>
>>>>>> >>> - tim
>>>>>> >>>
>>>>>> >>>> On 01/09/2014 12:22 PM, Patrick Shriwise wrote:
>>>>>> >>>> Hi all,
>>>>>> >>>>
>>>>>> >>>> Working on a set of tests in which I would like to read an ACIS file
>>>>>> >>>> independently in several different functions using
>>>>>> >>>> moab::Core::load_file. I believe that I am creating a new moab
>>>>>> >>>> instance in every function. However when I load the file
>>>>>> >>>> in a new function, the data from the original load seems to remain.
>>>>>> >>>> Any advice on how to load the file without having it
>>>>>> >>>> overlap between functions?
>>>>>> >>>>
>>>>>> >>>> Cheers,
>>>>>> >>> I've setup my local moab instance calls just as in MBTest.cpp and
>>>>>> >>> mb_vertex_coordinate_test but am still having the same problem. When
>>>>>> >>> I load a simple cube geometry and check that it has the appropriate
>>>>>> >>> number of vertices it works the first time, but if I repeat the test
>>>>>> >>> in main it will find twice the number of vertices as expected upon a
>>>>>> >>> repeated test run. Any thoughts?
>>>>>> > Hey all,
>>>>>> >
>>>>>> > Got this problem figured out. When loading a file using
>>>>>> > ReadCGM::load_file , a CGM instance is created which is persistent (see
>>>>>> > InitCGMA.cpp lines 65-80). This means that unless the CGMA geometry is
>>>>>> > removed before leaving ReadCGM, it still exists when loading another
>>>>>> > file or the same file whether this occurs in the same MOAB instance or
>>>>>> > not. By adding to ReadCGM a line calling delete_geometry() from CGM at
>>>>>> > the end of ReadCGM::load_file it allows the CGMA data to be removed and
>>>>>> > leave the existing MOAB Entities in tact.
>>>>>> >
>>>>>> > This leads to a question: Is there ever a case in which we would want to
>>>>>> > re-access the CGMA geometry data from a file after transferring it to
>>>>>> > MOAB (loading a file twice, loading multiple files into CGMA then moving
>>>>>> > it to MOAB, etc. ) or should this be the default behavior for ReadCGM?
>>>>>> > For the current DAGMC workflow its is not necessary or problematic that
>>>>>> > the CGM instance is persistent. Since we have all the ACIS geometry in a
>>>>>> > single file loaded once it is not an issue, however in testing that
>>>>>> > involves multiple file loads even in separate MOAB instances containing
>>>>>> > the original geometry AND the new geometry.
>>>>>> >
>>>>>> > Which leads up to my real question, will adding a delete_geometry() call
>>>>>> > from CGM cause problems in everyone else's workflow? (This change does
>>>>>> > not break other tests.)
>>>>>> >
>>>>>> >
>>>>>> > Thanks ,
>>>>>> >
>>>>>> > Patrick
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Patrick C. Shriwise
>>>>>> > Research Assistant
>>>>>> > University of Wisconsin - Madison
>>>>>> > Engineering Research Building - Rm. 428
>>>>>> > 1500 Engineering Drive
>>>>>> > Madison, WI 53706
>>>>>> > (608) 446-8173
>>>>>> >
>>>>>> >
>>>>
>>>
>>
>
>

-- 
================================================================
"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