|
[Sponsors] |
November 30, 2011, 07:33 |
face functionality for a DynamicList
|
#1 |
Senior Member
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 284
Blog Entries: 5
Rep Power: 21 |
Hi everyone,
I'm using the DynamicList for storing an extensively variable number of points and corresponding faces. If I want to use the face functionality that relies on the pointField, such as the face::normal or face::mag, the options I have considered so far are the following (please be kind and note that these are fast written small descriptive code snippets): 1) Templating the face class into tFace, and typedefing the template for the pointField: template< class Points > class tFace { private: // blah public: // blah blah, blabidi blah normal( const Points & ); mag (const Points & ); } and then to save myself: typedef genericFace<pointField> face; I'm sure this wouldn't break things, because the functionality of the face is preserved (I'm not making the face a different container, I'm just changing the Access functions part of the interface). Still, it's a bad habit to change the core library... so I'm skeptical. 2) I've tried slicing via references to avoid copying the data, but it doesn't work, the classes are distinct (diverging from List<T> into DynamicList and separately into Field<Type>). 3) I've tried brute force: the reinterpret_cast which just killed me because of the T* __restricted__ v_ in the UList (segmentation fault signal) 4) I've tried the xferMoveTo and friends, but: copying is the thing that I'm trying to avoid, this operation will be performed 100 of thousands of times in a single time step, xferMoveTo actually removes the data from the DynamicList and "puts it" into the pointField. 5) I'm thinking about switching the container to pointField, but I'm really skeptical because a lot of the algorithms rely on the DynamicList. 6) There is an option to do a local implementation of the algorithms, but I'm playing with the idea of re-using the code of the face class, otherwise if I do a local implementation, I may just use List<label> or write a small concrete type for my face... like... "dynamicFace" (inheriting from face wouldn't help here). Any thoughts on this? Tomislav |
|
November 30, 2011, 13:13 |
|
#2 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Isn't there a DynamicField class that you could use? It's identical to the Field class, but allows resizing.
|
|
November 30, 2011, 19:04 |
|
#3 | |
Senior Member
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 284
Blog Entries: 5
Rep Power: 21 |
Quote:
This works just fine: Code:
DynamicField<point> dPoints; dPoints.append(point(0,0,0)); dPoints.append(point(0,0,0)); dPoints.append(point(0,0,0)); dPoints.append(point(0,0,0)); face f(4); forAll(f, I) { f[I] = I; } f.mag(dPoints); |
||
Tags |
code re-use, dynamiclist, face, template |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Netgen] Import netgen mesh to OpenFOAM | hsieh | OpenFOAM Meshing & Mesh Conversion | 32 | September 13, 2011 06:50 |
[blockMesh] BlockMeshmergePatchPairs | hjasak | OpenFOAM Meshing & Mesh Conversion | 11 | August 15, 2008 08:36 |
fluent add additional zones for the mesh file | SSL | FLUENT | 2 | January 26, 2008 12:55 |
[blockMesh] Axisymmetrical mesh | Rasmus Gjesing (Gjesing) | OpenFOAM Meshing & Mesh Conversion | 10 | April 2, 2007 15:00 |
[Commercial meshers] Trimmed cell and embedded refinement mesh conversion issues | michele | OpenFOAM Meshing & Mesh Conversion | 2 | July 15, 2005 05:15 |