|
[Sponsors] |
Wrong behaviour when appending vector to vectorField? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
June 3, 2015, 03:20 |
Wrong behaviour when appending vector to vectorField?
|
#1 |
Member
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 92
Rep Power: 21 |
This code:
vectorField test; vector t1(1.0,2.0,3.0); test.append(t1); vector& t2 = test[0]; test.append(t2); Info << "test = " << test << endl; results in the following output: test = 2((1 2 3) (0 2 3)) The first component of the appended vector is not appended correctly. The error does not occur if t2 is a copy of test[0] rather than a reference to it. Here is the situation where I discovered the bug: //Calculate a pointField and if it only contains a single point //append this, so it occurs twice in the pointField pointField pf; someFunctionPopulatingPointField(pf); if (pf.size()==1) { pf.append(pf[0]); } The bug was reported here: http://www.openfoam.org/mantisbt/view.php?id=1729#c4882 It was marked as "resolved" by noting that one should work with a copy of instead of a reference to test[0]. As far as I can see this is not a fix but a work-around. Could some C++ expert comment on whether this is a genuine bug that should be properly fixed or if am I just doing dodgy stuff in my coding? |
|
June 3, 2015, 04:52 |
|
#2 |
Senior Member
|
Hi,
I would call this "undefined behaviour". If you take a look at how append method is implemented (Field is a child of List): Code:
template<class T> inline void Foam::List<T>::append(const T& t) { setSize(size()+1, t); } Code:
template<class T> void Foam::List<T>::setSize(const label newSize, const T& a) { label oldSize = label(this->size_); this->setSize(newSize); if (newSize > oldSize) { register label i = newSize - oldSize; register T* vv = &this->v_[newSize]; while (i--) *--vv = a; } } Now let's look at setSize implementation (src/OpenFOAM/containers/Lists/List/List.C:318), below is just relevant part Code:
template<class T> void Foam::List<T>::setSize(const label newSize) { ... if (newSize != this->size_) { if (newSize > 0) { T* nv = new T[label(newSize)]; if (this->size_) { ...copy old elements into newly allocated memory... if (this->v_) delete[] this->v_; this->size_ = newSize; this->v_ = nv; } ... } } |
|
June 3, 2015, 05:07 |
|
#3 |
Member
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 92
Rep Power: 21 |
Thanks a lot for that useful reply, alexeym!
I was not aware that appending to vectorFields and pointFields copied the whole field into new memory. The right thing to do in my particular case would probably be to work instead with a DynamicList<vector> (with an appropriately guessed initial size) instead of a vectorField. This way I'll avoid all that copying. |
|
June 3, 2015, 05:14 |
|
#4 |
Senior Member
|
Hi,
Well, not quite sure you can avoid copying with DynamicList: Code:
template<class T, unsigned SizeInc, unsigned SizeMult, unsigned SizeDiv> inline void Foam::DynamicList<T, SizeInc, SizeMult, SizeDiv>::setSize ( const label nElem ) { ... { capacity_ = max ( nElem, label(SizeInc + capacity_ * SizeMult / SizeDiv) ); } List<T>::setSize(capacity_); } // adjust addressed size List<T>::size(nElem); } |
|
June 3, 2015, 05:47 |
|
#5 |
Member
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 92
Rep Power: 21 |
Yes, hence my comment in brackets: "(with an appropriately guessed initial size)".
If for instance you know that your pointField/DynamicList<point> will be a subset of the points of a particular face in your mesh, just make sure to allocate memory for 'nFacePoints' points from the start to avoid copying. Cheers, Johan |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
problem during mpi in server: expected Scalar, found on line 0 the word 'nan' | muth | OpenFOAM Running, Solving & CFD | 3 | August 27, 2018 04:18 |
udf error | srihari | FLUENT | 1 | October 31, 2016 14:18 |
meshing of a compound volume in GMSH | shawn3531 | OpenFOAM | 4 | March 12, 2015 10:45 |
alpha1 wrong behaviour with LTSInterFoam | Quentin | OpenFOAM Running, Solving & CFD | 16 | January 10, 2015 09:56 |
Unstable behaviour after long period of stablility | plunge11 | FLUENT | 1 | April 6, 2011 09:15 |