COMP: restrict HashTable maxTableSize to int32 range
- avoids compiler warning about possible overflow (left-shift
operation) for label 64 compilations and we don't need anything
larger than int32 HashTable capacity anyhow.
ENH: make nearest power-of-two non-branching (previously brute-force)
Correcting bug introduced when trying to keep the old communicator.
We do not need local communicator if all ranks of comm have
some faces. Not all ranks of the already local communicator.
- previous handling of forced inclusion of the master would taint the
logic about single vs multiple ranks.
- be fussier about avoing creation of a local communicator when not
needed.
STYLE: rename internal switch from localComm_ to useLocalComm_
- less confusing (it is a switch, not the communicator itself)
- setting the warnComm is useful for diagnosing multi-world issues but
triggers many false warnings when used in combination with AMI local
communicators.
COMP: unresolved pTraits<long int> for reductions on i586 systems
- now always just use int64_t instead of off_t and time_t
for master reductions.
Note that this is not the only place where the off_t definition
causes compilation issues (cf. fileOperation::broadcastCopy)
- in many cases the local communicator has the same communication
pattern for several timesteps so it can be reused instead of being
recreated. Avoids repeated MPI_Comm_free()/MPI_Comm_group() calls
- STYLE: eliminate bitSet intermediate when determining the sub-ranks
Calculates thrust, drag, torque and lift/drag/pressure coefficients
of single or multiple blades (eg, propeller, turbine blades)
This function object differs from the propellerInfo and forces
function objects in that all forces are calculated within the local
cylindrical coordinate system, which yields thrust and drag values
within the expected reference frame.
The output comprises:
- coefficients per radial bin
- area-weighted total coefficients
- integrated forces and torque
For convenient post-processing, the results are also written in a VTK
(.vtp) output format. All surface results are registered internally,
which makes them available for other function objects.
- originally only listed in functionObjectList, now also list the same
information under namespace functionObjects so it is more likely to
be found. Document the behaviour as a table to make it more
immediately visible than the text form.
- the indices(const wordRes& allow, const wordRes& deny) methods
were not defined consistently with the wordRes::filter handling.
wordRes::filter - allow/deny both empty:
= no filtering (ie, accept everything)
indices(allow,deny) - allow/deny both empty:
= return identity list (NEW behaviour)
= return empty list (OLD behaviour)
Consider the old behaviour a minor bug since the limited number of
callers had their own checks that avoided the poor behaviour.
Example of the inconsistent behaviour:
pbm.indices(wordRes(), wordRes({"non-existent"}))
--> identity list (old, new behaviour)
pbm.indices(wordRes(), wordRes())
--> identity list (new behaviour)
--> empty list (old behaviour)
- tests for list equality with different but compatible data types.
Eg, when comparing lists of int32 and int64 values.
STYLE: pass UList instead of List references into ListOps functors
- avoids intermediate allocation and re-assignment to self (#3374)
BUG: checkMesh (application) with questionable memory handling (#3374)
- move the contents of the new points instead of attempting to transfer
the entire list
COMP: replace mapDistribute specializations with if constexpr handling
- simplify future maintenance
- in messageStream::masterStream(int), it forwarded to stream()
without the communicator, which meant it would incorrectly check
UPstream::master(worldComm) and possibly not produce any output (or
block).
ENH: align MPI_Probe non-blocking handling with header description
- the header states that the commsType is non-blocking or not,
but the implementation actually checked for 'buffered' or not.
STYLE: fix some spacing and some documentation
- use functionObject writeInterval not timeInterval.
No change in behaviour since the missing writeInterval is treated
as '1' anyhow when using 'timeStep' for the writeControl
- consistent use of 'adjustable' vs 'adjustableRunTime'
- prefer '#eval{ vector(...) }' to calling '#eval' multiple times
