<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div style="font-size:9px; color:#575757">Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone</div>
</div>
<br>
<br>
-------- Original message --------<br>
From: Paul Wilson <br>
Date:01/17/2014 4:33 PM (GMT-06:00) <br>
To: "Grindeanu, Iulian R." <br>
Cc: Patrick Shriwise ,"Tautges, Timothy J." ,moab-dev@mcs.anl.gov <br>
Subject: Re: [MOAB-dev] Closing/opening moab instances <br>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi all<br>
<br>
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.)<br>
<br>
We could add options to ReadCGM:<br>
• on/off delete on entering ReadCGM()<br>
• on/off delete on exiting ReadCGM()<br>
<br>
Paul<br>
<br>
-- -- <br>
Professor, Nuclear Engineering<br>
Faculty Director, Advanced Computing Infrastructure<br>
UW-Madison<br>
wilsonp@engr.wisc.edu, 608.263.0807<br>
Sent from my iPhone<br>
<br>
> On Jan 17, 2014, at 16:15, "Grindeanu, Iulian R." <iulian@mcs.anl.gov> wrote:<br>
> <br>
> I think we should call "delete_geometry" on cgm instance after read_cgm finishes its job.<br>
> I cannot think of any instance in which we would want the entities persistent.<br>
> maybe Rajeev has though issues when coregen-type calls are made in meshkit. I know that there multiple files
<br>
> 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;<br>
> <br>
> Thanks,<br>
> Iulian<br>
> ________________________________________<br>
> From: moab-dev-bounces@mcs.anl.gov [moab-dev-bounces@mcs.anl.gov] on behalf of Patrick Shriwise [shriwise@wisc.edu]<br>
> Sent: Friday, January 17, 2014 4:02 PM<br>
> To: Tautges, Timothy J.<br>
> Cc: moab-dev@mcs.anl.gov<br>
> Subject: Re: [MOAB-dev] Closing/opening moab instances<br>
> <br>
>> On 01/14/2014 09:46 AM, Patrick Shriwise wrote:<br>
>>> On 01/09/2014 12:43 PM, Tim Tautges (ANL) wrote:<br>
>>> Either declare the Core instance in a local variable, e.g. as in the<br>
>>> test/MBTest.cpp test (mb_vertex_coordinate_test function and the ones<br>
>>> following), or use Interface::delete_mesh. I'd recommend the former,<br>
>>> as that gives you a clean instance.<br>
>>> <br>
>>> - tim<br>
>>> <br>
>>>> On 01/09/2014 12:22 PM, Patrick Shriwise wrote:<br>
>>>> Hi all,<br>
>>>> <br>
>>>> Working on a set of tests in which I would like to read an ACIS file<br>
>>>> independently in several different functions using<br>
>>>> moab::Core::load_file. I believe that I am creating a new moab<br>
>>>> instance in every function. However when I load the file<br>
>>>> in a new function, the data from the original load seems to remain.<br>
>>>> Any advice on how to load the file without having it<br>
>>>> overlap between functions?<br>
>>>> <br>
>>>> Cheers,<br>
>>> I've setup my local moab instance calls just as in MBTest.cpp and<br>
>>> mb_vertex_coordinate_test but am still having the same problem. When<br>
>>> I load a simple cube geometry and check that it has the appropriate<br>
>>> number of vertices it works the first time, but if I repeat the test<br>
>>> in main it will find twice the number of vertices as expected upon a<br>
>>> repeated test run. Any thoughts?<br>
> Hey all,<br>
> <br>
> Got this problem figured out. When loading a file using<br>
> ReadCGM::load_file , a CGM instance is created which is persistent (see<br>
> InitCGMA.cpp lines 65-80). This means that unless the CGMA geometry is<br>
> removed before leaving ReadCGM, it still exists when loading another<br>
> file or the same file whether this occurs in the same MOAB instance or<br>
> not. By adding to ReadCGM a line calling delete_geometry() from CGM at<br>
> the end of ReadCGM::load_file it allows the CGMA data to be removed and<br>
> leave the existing MOAB Entities in tact.<br>
> <br>
> This leads to a question: Is there ever a case in which we would want to<br>
> re-access the CGMA geometry data from a file after transferring it to<br>
> MOAB (loading a file twice, loading multiple files into CGMA then moving<br>
> it to MOAB, etc. ) or should this be the default behavior for ReadCGM?<br>
> For the current DAGMC workflow its is not necessary or problematic that<br>
> the CGM instance is persistent. Since we have all the ACIS geometry in a<br>
> single file loaded once it is not an issue, however in testing that<br>
> involves multiple file loads even in separate MOAB instances containing<br>
> the original geometry AND the new geometry.<br>
> <br>
> Which leads up to my real question, will adding a delete_geometry() call<br>
> from CGM cause problems in everyone else's workflow? (This change does<br>
> not break other tests.)<br>
> <br>
> <br>
> Thanks ,<br>
> <br>
> Patrick<br>
> <br>
> <br>
> --<br>
> Patrick C. Shriwise<br>
> Research Assistant<br>
> University of Wisconsin - Madison<br>
> Engineering Research Building - Rm. 428<br>
> 1500 Engineering Drive<br>
> Madison, WI 53706<br>
> (608) 446-8173<br>
> <br>
> <br>
</div>
</span></font>
</body>
</html>