OpenFOAM-plus issueshttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues2019-09-28T13:57:21Zhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1431finite area non-orthogonal treament errors vs finite volume operators2019-09-28T13:57:21ZSergio Ferrarisfinite area non-orthogonal treament errors vs finite volume operatorsThe treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformit...The treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformity, specially close to the patches.
See aGradTx vs vGradTx.
laplacianFaFoam.tar is the fa solver
laplacianFoam is the fv solver.
The case cavity.tar contains the mesh and set up.
[aGradTx](/uploads/07f26b72d0b5cab79c334e8f4e9b7271/aGradTx.png)
[cavity.tar](/uploads/3a5a59a3b65fc071f00b99e64551df5b/cavity.tar)
[laplacianFaFoam.tar](/uploads/753a45d2a662a9bfd3a29b92a7afefbe/laplacianFaFoam.tar)
![vGradTx](/uploads/fabe63aa3fdef2f6c56fc1435a08873e/vGradTx.png)
The issue seems to be related to how the non-orthogonality is treated in the fam::laplacian,
special care should be taken for the non-orthogonality on the boundaries.v1912Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1391more expressive matrix method names2019-08-12T15:56:26ZMark OLESENmore expressive matrix method namesA problem was recently encountered by @philipc while porting some foam-extend code.
In the OpenFOAM Matrix class, we use `m()` for rows and `n()` for cols, whereas foam-extend use the opposite naming.
This obviously makes for some very d...A problem was recently encountered by @philipc while porting some foam-extend code.
In the OpenFOAM Matrix class, we use `m()` for rows and `n()` for cols, whereas foam-extend use the opposite naming.
This obviously makes for some very difficult error-finding.
Since there is nothing intrinsically meaningful about `m` and `n`, I suggest that we use `rows()` and `cols()` instead (method names as per Eigen3) and mark `m()` and `n()` as deprecated. This would help identify these types of pitfalls in the future.
Votes please: @andy @kuti @philipcv1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1381Incorrect indexing in adjointSolverManager2019-07-23T11:27:07ZAndrew HeatherIncorrect indexing in adjointSolverManagerIn the following the index should simply be `solveri` and not `objectiveSolverIDs_[solveri]`
```
scalar objValue(Zero);
for (const label solveri : objectiveSolverIDs_)
{
objectiveManager& objManager =
adjo...In the following the index should simply be `solveri` and not `objectiveSolverIDs_[solveri]`
```
scalar objValue(Zero);
for (const label solveri : objectiveSolverIDs_)
{
objectiveManager& objManager =
adjointSolvers_[objectiveSolverIDs_[solveri]].getObjectiveManager();
objValue += objManager.print();
}
```v1912Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1340low limit of cut-off frequency ignored in surfaceNoise2019-06-18T07:27:17ZSon Volow limit of cut-off frequency ignored in surfaceNoisesurfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://...surfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://exchange.openfoam.com/node/1038
Son.v1912Andrew HeatherAndrew Heather