Activity for Daniel Khazaei
-
Daniel Khazaei created ticket #39
[foam-extend-4.1]: piso/pimple unstable
-
Well I reported this issue a while back and I was not aware that unlike OpenFOAM, foam-extend reads local controlDict. However, I managed to find the solution soon after submitting the ticket: https://sourceforge.net/p/foam-extend/tickets/18/#3b7f I don't know what is wrong on @Stefan Bošković side, but it is working here since then. Although, compiling a dynamic code in a parallel run is considerably slower comparing to a serial run, is it expected?
-
Well I reported this issue a while back and I was not aware that unlike OpenFOAM, foam-extend reads local controlDict. However, I managed to find the solution soon after submitting the ticket: https://sourceforge.net/p/foam-extend/tickets/18/#3b7f I don't know what is wrong on @Stefan Bošković side, but it is working here since then. Although compiling a dynamic code in a parallel run is considerably slower comparing to a serial run, is that expected?
-
[foam-extend-4.1]: parallel cases crash when GAMG is selected for pEqn
-
[port]: completed List container implementation with new functions.
-
Suppress Gcc-8 warnings
-
[bugfix]: writing to an object with no trivial copy-assignment [wclass-memaccess].
-
[port]: disabled flex++ warnings during foam compile.
-
[port]: re-write List container to suppress [-Walloc-size-larger-than=].
-
[bugfix]: corrected APPBIN path for RichardsFoam solver.
-
[port]: re-write List container to suppress [-Walloc-size-larger-than=].
-
[port]: re-write List container to suppress [-Walloc-size-larger-than=].
-
[port]: re-write List container to suppress [-Walloc-size-larger-than=].
-
[bugfix]: fixed ggc-8 warning: writing to an object with no trivial copy-assignment.
-
[port]: re-write List container to suppress [-Walloc-size-larger-than=].
-
foam-extend future plans
-
64-bit label bugfix for refinement utility of dynamicMesh
-
[bugfix]: fixed 64-bit label compile failure.
-
Dear H. Jasak, Is there any reason that commits from the recent merge requests are not visible on the nextRealease branch despite of a change in their status(open --> merged)? Regards
-
I have noticed the problem when I was trying to model a boiling mechanism of incompressible two-phase flow inside a closed-loop thermosyphon without any inlet/oulet boundary conditions. The fixedFluxedPressure pressure boundary condition is applied on the walls and no slip boundary condition is used for the velocity field. I have a temperature-dependent mass transfer source term in pdEqn as follow: fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); The problem...
-
I have noticed the problem when I was trying to model a boiling mechanism of incompressible two-phase flow inside a closed-loop thermosyphon without any inlet/oulet boundary conditions. The fixedFluxedPressure pressure boundary condition is applied on the walls and no slip boundary condition is used for the velocity field. I have a temperature-dependent mass transfer source term in pdEqn as follow: fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); The problem...
-
I have noticed the problem when I was trying to model a boiling mechanism of incompressible two-phase flow inside a closed-loop thermosyphon without any inlet/oulet boundary conditions. The fixedFluxedPressure pressure boundary condition is applied on the walls and no slip boundary condition is used for the velocity field. I have a temperature-dependent mass transfer source term in pdEqn as follow: fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); The problem...
-
I have noticed the problem when I was trying to model a boiling mechanism of incompressible two-phase flow inside a closed-loop thermosyphon without any inlet/oulet boundary conditions. The fixedFluxedPressure pressure boundary condition is applied on the walls and no slip boundary condition is used for the velocity field. I have a temperature-dependent mass transfer source term in pdEqn as follow: fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); The problem...
-
I have noticed the problem when I was trying to model a boiling mechanism of incompressible two-phase flow inside a closed-loop thermosyphon without any inlet/oulet boundary conditions. The fixedFluxedPressure pressure boundary condition is applied on the walls and no slip boundary condition is used for the velocity field. I have a temperature-dependent mass transfer source term in pdEqn as follow: fvScalarMatrix pdEqn ( fvc::div(phiHbyA) - fvm::laplacian(rAUf, pd_) - (vDotc - vDotv) ); The problem...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
Yes the only bugfix as stated by commit [4e046a] is the label fix in the last function and the rest of the changes are only enhancments. Commit [f7bfb3] is just an improvment to findRefCell utility to keep track of changes in OpenFOAM-dev. As it can been seen the main code is untouched and only the structure has been re-written whcih provides a few simplicities. setRefCell function is now boolean instead of void which is usefull if we need to use it as a conditional clause. setRefCell function can...
-
[enh]: backported upstream (OpenFOAM-dev) changes to findRefCell utility.
-
critical bug in getRefCellValue function
-
[bugfix]: getRefCellValue returns truncated label instead of a scalar.
-
[bugfix]: 64-bit label bugfix some how got overwritten by cfMesh update.
-
[bugfix]: 64-bit label bugfix some how got overwrited by cfMesh update.
-
[cxx-syntax]: consistent usage of nullptr.
-
gcc8 compliance improvments
-
[bugfix]: recover velocity field in a more general way.
-
[format]: make forward declaration style consistent.
-
[bugfix]: friend operators need forward declaration to avoid gcc warning.
-
format: make cfMesh banner consistent and removed trailing whitespace
-
well, I have compiled and tested several cases without any problems. Also swak4Foam (modified), waves2Foam and fluidSolidInteraction(modified) packages can be compiled without any problems. So in my opinion, we can close this issue... I have fixed a few warnings here: https://sourceforge.net/p/foam-extend/foam-extend-4.0/merge-requests/97/ However, I don't fully understand this: https://sourceforge.net/p/foam-extend/tickets/24/
-
GCC8 compatibility improvments
-
Bugfix: update cfMesh to v1.1 which fixes self-comparison always evaluates to false [-Wtautological-compare]
-
Bugfix: Added support for openmpi 4.0.0 and updated c++ casting style to suppress [-Wold-style-cast]
-
Bugfix: fixed the compiler can assume that the address of ‘t’ will never be NULL warning [-Waddress]
-
CXX-syntax: updated tecio c++ casting style to suppress [-Wold-style-cast]
-
Bugfix: type qualifiers ignored on cast result type
-
Bugfix: overflow in conversion from Foam::label to int
-
warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized]
-
Hi Bernhard, I have tested the latest commit made by Henrik, got the following error with swak4Foam: generalInterpreterWrapper.C: In member function ‘void Foam::generalInterpreterWrapper::scatterGlobals()’: generalInterpreterWrapper.C:590:31: error: no match for ‘operator<’ (operand types are ‘Foam::label’ {aka ‘long int’} and ‘const Foam::debug::optimisationSwitch’) if (Pstream::nProcs() < Pstream::nProcsSimpleSum) fixed that by: if (Pstream::nProcs() < Pstream::nProcsSimpleSum()) So now this: is...
-
Hi Bernhard, I have tested the latest commit made by Henrik, got the following error with swak4Foam: generalInterpreterWrapper.C: In member function ‘void Foam::generalInterpreterWrapper::scatterGlobals()’: generalInterpreterWrapper.C:590:31: error: no match for ‘operator<’ (operand types are ‘Foam::label’ {aka ‘long int’} and ‘const Foam::debug::optimisationSwitch’) if (Pstream::nProcs() < Pstream::nProcsSimpleSum) fixed that by: if (Pstream::nProcs() < Pstream::nProcsSimpleSum())
-
Hi Bernhard, I have tested the latest commit made by Henrik, got the following error with swak4Foam: generalInterpreterWrapper.C: In member function ‘void Foam::generalInterpreterWrapper::scatterGlobals()’: generalInterpreterWrapper.C:590:31: error: no match for ‘operator<’ (operand types are ‘Foam::label’ {aka ‘long int’} and ‘const Foam::debug::optimisationSwitch’) if (Pstream::nProcs() < Pstream::nProcsSimpleSum) fixed that by: if (Pstream::nProcs() < Pstream::nProcsSimpleSum**()**)
-
Dear Bernhard Gschaider, Just noticed that you have also replied in here. This should work without breaking other distributions...tested on both OpenFOAM-v1812 and foam-extend-4.1 with WM_LABEL_SIZE=64! The reason I emailed you the patch is that whenever I try to push my new branch, I get the following error: hg push --new-branch pushing to http://hg.code.sf.net/p/openfoam-extend/swak4Foam searching for changes abort: HTTP Error 403: Forbidden Regards
-
Dear Henrik, I have provided the results of the following commands to the maintainer at bgschaid@hfd-research.com. hg clone http://hg.code.sf.net/p/openfoam-extend/swak4Foam hg update develop hg branch hotfix/64BitLabel (modifying files) hg add hg commit -m "BUGFIX: Compile WM_LABEL_SIZE=64" hg export -o 64BitLabel.patch 3108892b176f patched files list: foam-extend-4.1 and OpenFOAM-v1812 shiftFieldGeneralPluginFunction.C foam-extend-4.1 only pythonInterpreterWrapper.C python3InterpreterWrapper.C...
-
yes, I can do that! however I'm relatively new in using git and just started to learn by forking a mirror of https://sourceforge.net/p/foam-extend/foam-extend-4.0/ci/master/tree/ to my gitlab account. What I need to do is fork the current development branch of swak4Foam ( http://hg.code.sf.net/p/openfoam-extend/swak4Foam/file/c647257ad598 ) and then request for a merge after commiting the changes?
-
yes, I can do that! however I'm relatively new in using git and just started to learn by forking a mirror of https://sourceforge.net/p/foam-extend/foam-extend-4.0/ci/master/tree/ to my gitlab account. What I need to do is fork the current development branch of swak4Foam (http://hg.code.sf.net/p/openfoam-extend/swak4Foam/file/c647257ad598) and then request for a merge after commiting the changes?
-
thanks alot, that fixed the error!
-
managed to fixed 2 out 3 errors, I dont realy understand the last error...
-
now the latest swak4Foam fails to build under 64-bit, log is attached...
-
Dear Henrik, I can confirm that the problem has been fixed and the source can now be compiled with WM_LABEL_SIZE set to 64.
-
Dear Henrik, I have almost finished applying the fixes based on the commits a48ee8b and 40cad3c! However I can't find the 64-bit patches of metis, scotch and ParMGridGen in here: https://sourceforge.net/u/henrus/foam-extend-4.0/ci/bugfix/64BitLabel/%7E/tree/ThirdParty/rpmBuild/SOURCES/
-
Dear Henrik, I have almost finished applying the fixes based on the commits a48ee8b and 40cad3c! However I can't find the 64-bit patches of metis, scotch and ParMGridGen in the here: https://sourceforge.net/u/henrus/foam-extend-4.0/ci/bugfix/64BitLabel/%7E/tree/ThirdParty/rpmBuild/SOURCES/
-
Dear Henrik, thank you for looking into this problem, however I cant access the link you have posted! Using git clone ssh://henrus@git.code.sf.net/u/henrus/foam-extend-4.0 requires password... if I can see the corrosponding commits, I can make the changes on my local repo and will let you know if its working. Edit: never mind, found the corrosponding commits in your profile! will try to apply them and report back... Regards, Daniel
-
Dear Henrik, thank you for looking into this problem, however I cant access the link you have posted! Using git clone ssh://henrus@git.code.sf.net/u/henrus/foam-extend-4.0 requires password... if I can see the corrosponding commits, I can make the changes on my local repo and will let you know if its working. Regards, Daniel
-
Dear Henrik, thank you for looking into this problem, however I cant access the link you posted! Using git clone ssh://henrus@git.code.sf.net/u/henrus/foam-extend-4.0 requires password... if I can see the corrosponding commits, I can make the changes on my local repo and will let you know if its working. Regards, Daniel
-
nextRelease branch compile fails when WM_LABEL_SIZE=64
-
corrupted size vs prev_size nextRelease
-
well, managed to solve the problem! apparently allowSystemOperations should be defined in the local controlDict and the error shown by dynamicCode.C is misleading about the global controlDict which is not being read anymore!
-
dynamicCode functionality
1
