September 2013 - cgma-dev - mailman3.cels.anl.gov

Re: [cgma-dev] (no subject)
by Jane Hu 30 Sep '13

30 Sep '13

Huayi， In case you are wondering about how to model facets of triangles into a geometry surface in cgm, here's the hint: Under cgm/geom/facet, the call FacetModifyEngine::build_cholla_surfaces() should give you a pointer to ChollaEngine. >From ChollaEngine you can get ChollaSurface pointer: ChollaEngine::get_surfaces( DLIList<ChollaSurface *> & cholla_surface_list ) For your case, there should be only one ChollaSurface generated. Get its EvalTool by get_eval_tool(). Then use the EvalTool to call project_to_facets(CubitVector &this_point, CubitBoolean trim, CubitBoolean *outside, CubitVector *closest_point_ptr, CubitVector *normal_ptr); You should get all related info from this call then. Hope it helps. Jane On Sun, Sep 29, 2013 at 9:59 PM, 魏华祎 <huayiwei1984(a)gmail.com> wrote: > Hi, There, > > I have a polyhedral surface whose all of facets are triangles. Can > cgma do such things: given a point near this surface, then project the > point to this surface? I am a newbie of cgma. I need your help, thanks very > much. > > Best > > Huayi > > > > -- Jane Hu Asst. Researcher Dept. of Engineering Physics UW @ Madison "And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)

1 0

Re: [cgma-dev] (no subject)
by Jane Hu 30 Sep '13

30 Sep '13

Hello, >From what you described, you may want to use Surface::closest_point_trimmed(CubitVector from_point, CubitVector& point_on_surface) to get your projected point. Good luck for your code! Jane On Sun, Sep 29, 2013 at 9:59 PM, 魏华祎 <huayiwei1984(a)gmail.com> wrote: > Hi, There, > > I have a polyhedral surface whose all of facets are triangles. Can > cgma do such things: given a point near this surface, then project the > point to this surface? I am a newbie of cgma. I need your help, thanks very > much. > > Best > > Huayi > > > > -- Jane Hu Asst. Researcher Dept. of Engineering Physics UW @ Madison "And we know that for those who love God, that is, for those who are called according to his purpose, all things are working together for good." (Romans 8:28)

1 0

(no subject)
by 魏华祎 29 Sep '13

29 Sep '13

Hi, There, I have a polyhedral surface whose all of facets are triangles. Can cgma do such things: given a point near this surface, then project the point to this surface? I am a newbie of cgma. I need your help, thanks very much. Best Huayi

1 0

Re: [cgma-dev] Switching unique IDs to RFC4122 UUIDs
by David Thompson 24 Sep '13

24 Sep '13

Hi Clinton, >>> I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to >>> RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across >>> multiple large models are much less likely to have duplicate IDs. > > Keeping track of the current file and entities being read is a good approach. Yes, but something we want is an ID that can reference entities which may be in multiple files. Tracking the current file with an integer defined by the load order doesn't provide a way to do that. > Even if you have a better unique id (e.g. RFC 4122), you will still have > collisions when importing the same file twice. Actually that should not happen with RFC 4122 UUIDs as all the variants use a random number generator seeded with something involving the current time (or use the time directly in the UUID). > By the way, its nice to see Kitware using CGM. I'm curious what its being used for. We are looking at it for a modeling and simulation workflow framework. David

1 0

Re: [cgma-dev] Switching unique IDs to RFC4122 UUIDs
by David Thompson 24 Sep '13

24 Sep '13

Hi Tim, >> I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across multiple large models are much less likely to have duplicate IDs. > > While I think this is worth considering (and doing, if it were just CGM), I'm not sure it's so critical for file operations. I'm not sure what you mean by "file operations." >> One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. ... >> Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I thought lived in different "namespaces" (sequential integers for CAUniqueId and random integers for TDUniqueId). Was I wrong to think this? If not, why does CAEntityId add the same id_inc to both its own ID and its merge-partner's (which appears to be obtained in some places using TDUniqueId::find_td_unique_id)? > > Here I think you're wrong, the unique id and entity id are different concepts, and the find_td_unique_id in CAEntityId is used strictly with UIDs and not with entity ids. Thanks, I will take a more careful look there. > To summarize, while I think it would be useful to use a standards-compliant UUID, in practice I'm guessing it's going to be difficult to motivate the Cubit project to change what they do to accomplish this, even if you/we implement all the changes in CGM and below. Cubit guys, please chime in here. It appears to me that GSaveOpen was probably meant to do what a true UUID change would, that is, guarantee different UUID spaces in different files, alas they solved it a different way. OK. If we cannot find a good way to get by without UUIDs then we'll look to add them as a third attribute instead of a replacement for TDUniqueID. Thanks, David

1 0

Re: [cgma-dev] Switching unique IDs to RFC4122 UUIDs
by Clinton Stimpson 24 Sep '13

24 Sep '13

On Monday, September 23, 2013 03:07:29 PM Tim Tautges wrote: > [cc'ing cubit-dev, since they will also want to weigh in on this...] > > On 09/20/2013 04:08 PM, David Thompson wrote: > > Hi all, > > > > I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to > > RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across > > multiple large models are much less likely to have duplicate IDs. > While I think this is worth considering (and doing, if it were just CGM), > I'm not sure it's so critical for file operations. Large models are indeed > likely to have conflicting ids with other large files, but those could be > handled by keeping track of the current file you're reading and the > entities read by each file (not efficient, I know, but simple to > implement). > > > One problem I am having is that CGMA performs math (addition/subtraction) > > on UUIDs in places. For instance, SubEntitySet::renumerate, > > CAEntityId::actuate, and PartitionEngine::restore_from_attrib all do some > > kind of math (increment/decrement) on UIDs. This is not supported by any > > UUID implementation I'm aware of. > Looking at CAEntityId::actuate, and the GSaveOpen::get_id_inc, it appears > that this increment is used in place of a file id or indicator (haven't > checked that to be sure, but I'd be very surprised if that wasn't the > case), but that's for entity ids, not for unique ids. SubEntitySet's use > seems like EntityId, not UID; same goes for > PartitionEngine::restore_from_attrib. > > > Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I > > thought lived in different "namespaces" (sequential integers for > > CAUniqueId and random integers for TDUniqueId). Was I wrong to think > > this? If not, why does CAEntityId add the same id_inc to both its own ID > > and its merge-partner's (which appears to be obtained in some places > > using TDUniqueId::find_td_unique_id)? > > Here I think you're wrong, the unique id and entity id are different > concepts, and the find_td_unique_id in CAEntityId is used strictly with > UIDs and not with entity ids. > > To summarize, while I think it would be useful to use a standards-compliant > UUID, in practice I'm guessing it's going to be difficult to motivate the > Cubit project to change what they do to accomplish this, even if you/we > implement all the changes in CGM and below. Cubit guys, please chime in > here. It appears to me that GSaveOpen was probably meant to do what a true > UUID change would, that is, guarantee different UUID spaces in different > files, alas they solved it a different way. > Hi, Keeping track of the current file and entities being read is a good approach. Even if you have a better unique id (e.g. RFC 4122), you will still have collisions when importing the same file twice. In that case, GSaveOpen serves a purpose to help reference entities local to the current file being imported, which UUIDs cannot help with. Aside from that, in the past, a couple of us have informally talked about wanting to use a standard UUID in CGM to reduce collisions. I think its a good idea. By the way, its nice to see Kitware using CGM. I'm curious what its being used for. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com

1 0

Re: [cgma-dev] Switching unique IDs to RFC4122 UUIDs
by Tim Tautges 23 Sep '13

23 Sep '13

[cc'ing cubit-dev, since they will also want to weigh in on this...] On 09/20/2013 04:08 PM, David Thompson wrote: > Hi all, > > I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to RFC4122-style UUIDs (16 bytes, unsigned) so > that cross-references across multiple large models are much less likely to have duplicate IDs. > While I think this is worth considering (and doing, if it were just CGM), I'm not sure it's so critical for file operations. Large models are indeed likely to have conflicting ids with other large files, but those could be handled by keeping track of the current file you're reading and the entities read by each file (not efficient, I know, but simple to implement). > One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. For instance, > SubEntitySet::renumerate, CAEntityId::actuate, and PartitionEngine::restore_from_attrib all do some kind of math > (increment/decrement) on UIDs. This is not supported by any UUID implementation I'm aware of. > Looking at CAEntityId::actuate, and the GSaveOpen::get_id_inc, it appears that this increment is used in place of a file id or indicator (haven't checked that to be sure, but I'd be very surprised if that wasn't the case), but that's for entity ids, not for unique ids. SubEntitySet's use seems like EntityId, not UID; same goes for PartitionEngine::restore_from_attrib. > Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I thought lived in different "namespaces" > (sequential integers for CAUniqueId and random integers for TDUniqueId). Was I wrong to think this? If not, why does > CAEntityId add the same id_inc to both its own ID and its merge-partner's (which appears to be obtained in some > places using TDUniqueId::find_td_unique_id)? Here I think you're wrong, the unique id and entity id are different concepts, and the find_td_unique_id in CAEntityId is used strictly with UIDs and not with entity ids. To summarize, while I think it would be useful to use a standards-compliant UUID, in practice I'm guessing it's going to be difficult to motivate the Cubit project to change what they do to accomplish this, even if you/we implement all the changes in CGM and below. Cubit guys, please chime in here. It appears to me that GSaveOpen was probably meant to do what a true UUID change would, that is, guarantee different UUID spaces in different files, alas they solved it a different way. - tim > > Thanks, David > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 0

Switching unique IDs to RFC4122 UUIDs
by David Thompson 20 Sep '13

20 Sep '13

Hi all, I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across multiple large models are much less likely to have duplicate IDs. One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. For instance, SubEntitySet::renumerate, CAEntityId::actuate, and PartitionEngine::restore_from_attrib all do some kind of math (increment/decrement) on UIDs. This is not supported by any UUID implementation I'm aware of. Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I thought lived in different "namespaces" (sequential integers for CAUniqueId and random integers for TDUniqueId). Was I wrong to think this? If not, why does CAEntityId add the same id_inc to both its own ID and its merge-partner's (which appears to be obtained in some places using TDUniqueId::find_td_unique_id)? Thanks, David

1 0

cgma configure error : "mpi.h not found or not working"
by 魏华祎 14 Sep '13

14 Sep '13

Hi, there, I checked out the revison 6070 from cgm/tunk. When I configure it with mpi, there will appear error "mpi.h not found or not working". My system is Ubuntu 12.04 64 bit desktop, and the default installed directory of mpi is "/usr/lib/openmpi/". Is this error a bug? Best Huayi

1 0

r6070 - cgm/trunk
by janehu＠mcs.anl.gov 12 Sep '13

12 Sep '13

Author: janehu Date: 2013-09-12 10:40:11 -0500 (Thu, 12 Sep 2013) New Revision: 6070 Modified: cgm/trunk/README.OpenCascade Log: Minor change for message on cgm on occ capabilities. Modified: cgm/trunk/README.OpenCascade =================================================================== --- cgm/trunk/README.OpenCascade 2013-09-12 14:49:11 UTC (rev 6069) +++ cgm/trunk/README.OpenCascade 2013-09-12 15:40:11 UTC (rev 6070) @@ -1,4 +1,4 @@ - CGM on OCC6.5 capabilities + CGM on OCC capabilities 1. Query

1 0