[MOAB-dev] Closing/opening moab instances

[Paul Wilson]

> On Jan 17, 2014, at 20:48, "Tautges, Timothy J." <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, 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 
> 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, 608.263.0807
> Sent from my iPhone
> 
> > On Jan 17, 2014, at 16:15, "Grindeanu, Iulian R." <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 [moab-dev-bounces at mcs.anl.gov] on behalf of Patrick Shriwise [shriwise at wisc.edu]
> > Sent: Friday, January 17, 2014 4:02 PM
> > To: Tautges, Timothy J.
> > Cc: 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
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140118/f15e3add/attachment-0001.html>