[MOAB-dev] Closing/opening moab instances

[Patrick Shriwise]

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? 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?

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


-- 
Patrick C. Shriwise
Research Assistant
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173