[MOAB-dev] Closing/opening moab instances

Paul Wilson wilsonp at engr.wisc.edu
Mon Jan 20 14:10:12 CST 2014 

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.

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

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140120/2f347bb4/attachment.bin>

More information about the moab-dev mailing list