CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   face functionality for a DynamicList (http://www.cfd-online.com/Forums/openfoam-programming-development/94925-face-functionality-dynamiclist.html)

tomislav_maric November 30, 2011 07:33

face functionality for a DynamicList
 
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

deepsterblue November 30, 2011 13:13

Isn't there a DynamicField class that you could use? It's identical to the Field class, but allows resizing.

tomislav_maric November 30, 2011 19:04

Quote:

Originally Posted by deepsterblue (Post 334163)
Isn't there a DynamicField class that you could use? It's identical to the Field class, but allows resizing.

Thanks Sandeep! :)

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);

I'll check the class out some more tomorrow when I get some sleep... it seems (from the public part of the interface) similar to DynamicList... but because it's inherited from the Field I can feed it to the face. :cool: Coolio. Thanks again! :)


All times are GMT -4. The time now is 08:43.