[MOAB-dev] Closing/opening moab instances

Paul Wilson wilsonp at engr.wisc.edu
Mon Jan 20 14:11:30 CST 2014 

P.S. It is something we are happy to fix/change once we agree on the 
right behavior.

Paul

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.
>
> 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/69287c09/attachment-0001.bin>

More information about the moab-dev mailing list