- in case of cell overlapping a patch : set cell to hole always
- in case of cell changing from hole to calculated: set to hole
and continue. Do so before 'flood filling' holes.
Patch supplied by Nicolas Edh.
- unnecessary. Can deduce labelRange from the pair of labels.
These are all the same:
list[labelRange(18,3)] = 100;
list[labelRange{18,3}] = 100;
list[{18,3}] = 100;
Removing the run-time handling of std::initializer_list in favour of
compile-time deduction allows the future use of sliceRange as well.
Eg,
list[sliceRange{18,3,2}] = 100;
list[{18,3,2}] = 100;
- Enhancements provided by Y. Inoue at RIST (http://www.hpci-office.jp)
- Use allToAll to only swap local data (excludes master processor; saves memory)
- Memory saving is noticeable >= 4000 cores
- fix typo in makefiles/info that affected wmake -show-compile-c
- additional safeguard in src/OpenFOAM/Make/options against self-linking.
This is not normally required unless PROJECT_LIBS has been added into
the link stage.
- extracts values from the arch "LSB;label=32;scalar=64" header entry
to provision for managing dissimilar primitive sizes.
Compensate for the additional IOobject members by narrowing the types
for the (objectState, readOption, writeOption) enumerations
- with the changes added in #1256 and corresponding updates to
ThirdParty we can stop exporting these variables:
WM_CC WM_CFLAGS WM_CXX WM_CXXFLAGS WM_LDFLAGS
solaris:
- rename WM_ARCH from SunOS to solaris64 for consistency with wmake/rules
- drop non-64 solaris from wmake/rules
- remove automatic selection of FJMPI. This should be done in the bashrc
or prefs.sh file instead.
- remove old (likely inaccurate) exported flags, rely on wmake -show-xyz
or user config instead
darwin:
- remove '-Ddarwin' from the exported WM_CFLAGS, WM_CXXFLAGS.
Not used elsewhere (ThirdParty)
- the only code location using BiIndirectList are debug sections
within polyTopoChange.
No need to construct/assign directly from a BiIndirectList since
the '()' method provides a simple alternative.
- use an IndirectListBase class for various indirect list types.
- new SortList type
In some places the SortList can be used as a lightweight alternative
to SortableList to have the convenience of bundling data and sort
indices together, but while operating on existing data lists.
In other situations, it can be useful as an alternative to
sortedOrder. For example,
pointField points = ...;
labelList order;
sortedOrder(points, order);
forAll(order, i)
{
points[order[i]] = ...;
}
Can be replaced with the following (with the same memory overhead)
pointField points = ...;
SortList<point> sortedPoints(points);
for (point& pt : sortedPoints)
{
pt = ...;
}
- new SliceList type (#1220), which can be used for stride-based
addressing into existing lists
