Activity for Hrvoje Jasak
-
Hrvoje Jasak modified ticket #81
Help with invalid relocation type 42
-
What operating system are you on? Can you confirm as many of the variables as you can, eg. compiler, linker binutils etc? If I am reading this right, your bison isn't working either, meaning that there is something fundamentally broken with your installation. For the record, I am on Ubuntu-20.04 and 22.04 and stuff works. There were some problems with gcc-12, but it seems the compiler is broken.
-
New environment variables for locating the system-installed version of the Metis, ParMetis and Scotch packages.
-
Hi, The code fails in the thermo package because h boundary condition on the immersed boundary patch is set to a default patch field type (immersed boundary) that should not be used. There are options on how to fix this, ie either specify the h field or change the hBoundaryTypes to support immersed boundary. This is broken in the entire OpenFOAM, for all coupled implicit or special boundary types which are not spefically listed in functions such as hBoundaryTypes or heBoundaryTypes. A good virtual...
-
Problem with large parallel run: increasing memory usage with increasing number of nodes
-
Hi Guys, Sergey, thank you - excellent work. I have applied the patch on my machine: how can I test that everything is correct? Is it safe to push this into nextRelease and run with it fur a while? Hrv
-
This is bizarre. I am on gcc-9.3.0 and there isn't a problem. I think it will be because of unsigned ints. I don't want to change a compiler, and this is not related to c++-17 (I tried). What you can do is to take this constructor from label - there are 2: //- Construct from a list of labels // using the labels as indices to indicate which bits are set explicit inline PackedBoolList(const UList<label>& indices); //- Construct from a list of labels // using the labels as indices to indicate which...
-
Hi, You can switch the flag in linux64Gcc/c++ (or equivalent) in foam-extend-5.0/wmake/rules I have now compiled everything using c++-17 and there was only one fix in NamedEnum. The rest compiles fine. If you wish to use this, please check out the nextRelease branch, as follows: git clone -b nextRelease <blah blah=""> foam-extend-5.0</blah> and compile. Most porting changes are in the nextRelease branch, as we are due for foam-extend-5.0 anyway. Hope this helps, Hrvoje
-
Hi, The relaxation statement of p (or indeed pd) has been removed in nextRelease as it does nothing. Regarding the other change: rho == alpha1rho1 + (scalar(1) - alpha1)rho2; This is actually wrong: you need to call a boundary condition update. If this gives you problems with rho, it may be something else. I can have a look if you can share a case.
-
Hi, I think I fixed all of this, around 15/Sep. I assume you are using the master branch. Can you please re-pull and check. I am no Ubuntu-20.04 gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) and it compiles without errors. Please let me know, Hrv
-
Hi, I think this is now all fixed in the nextRelease branch. Since I cannot change the bc-s programmatically, they should be included in the initial field of the rothalpy at time zero. Can you check if it works now? I am happy to chare the tutorial, Hrv
-
I agree. I was debugging David Hora and not foam-extend. The net cost on my side is GBP 200 for no gain.
-
I agree. I was debugging David Hora and not foam-extend. The net coat on my side is GBP 200 for no gain.
-
Convergence issues with potentialFoam
-
Broken mesh, bad settings, inexpert user. checkMesh: Number of edges not aligned with or perpendicular to non-empty directions: 24545 Pic shows broken cells. THE SOLVER IS FINE. You will notice that the solver produces a z-direction velocity (how did you miss that?). Please stop wasting my time; you need a support contract and not a bug tracker.
-
Bugs in wall distance caluclation
-
faMatrix: Calculation of the residual possibly affects the source
-
Correct, and corrected. The one in fvMatrix has already been corrected some time ago. Thank you!
-
Assessing the difficulty of porting block solvers to recent OpenFOAM
-
you are probably looking at Copyright violation as the biggest problem. Beware what you sign
-
Not a bug.
-
I am not sure I understand. If the relative velocity of the wall is not fixed to zero, you will have a flux (= flow) going through the wall. This is very probably wrong. I think the problem is in your understanding of the way the code works. Apologies, cannot help.
-
This is not necessarily a problem - you can try to implement this yourself. There are 2 issues: 1) from the coupled solver you need to determine which are the scalar and which are vector/tensor components. The scalars get transferred without modification, while vectors/tensors need transformation matrix applied to the opposite side 2) You now have a choice: either perform the transformation first and then do the multiplication OR include the transformation tensor directly on the coefficient of vector/tensor...
-
Correct. This is a development item, as a medium-sized refactoring job is required. Can you provide funding?
-
Add parameters to the "-dumpControlSwitches" command-line option
-
Adjustments to the definition of 2 global Info switches
-
tutorials fix: add missing potentialFlow subdict in many tutorials' fvSolution file
-
Hello All, I am getitng a bit bored with the turbomachinery interfaces tutorials failing. The code is fine, but tutorials are trivial and people expect real results. Recently, we did a full validation study for all types of interfaces using contra-rotating propellers: https://cfd.fsb.hr/wp-content/uploads/2019/03/LukaBalatinecMSc_2019.pdf This has full props, transient, frozen rotor, cyclics, partial overlap, single channel and mixing plane. Shall we find a way to use this as a validation suite for...
-
I can't do it there because on topological change or load balancing it deletes my meshObjects and I cannot have that happen. It definitely needs to be cleared in the destructor only, but I am not sure where. Under investigation...
-
Bugfix for OBJ file reader. Accessing content of a string at index -1
-
Test harness: path adjustments for version 5.0
-
I am sorry - would you kindly explain precisely what you meant by your comment.
-
Cannot reproduce - see #34 Are you sure you know what you are doing? git log commit f2c557318fe73d31f2784b614998e85e0fd79761 Author: Hrvoje Jasak h.jasak@wikki.co.uk Date: Wed Apr 8 18:23:43 2020 +0100 git branch * master pwd foam-extend-4.1/tutorials/incompressible/simpleFoam/motorBike Starting time loop Time = 1 smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.04761956263, No Iterations 4 smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations...
-
Cannot reproduce: solvers { p { solver GAMG; tolerance 1e-7; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; } mpirun -np 6 simpleFoam -parallel | tee log Starting time loop Time = 1 smoothSolver: Solving for Ux, Initial residual = 0.009031187173, Final residual = 0.0008850137443, No Iterations 3 smoothSolver: Solving for Uy, Initial residual = 0.1494645189, Final residual = 0.01126218264, No...
-
Probably not a bug. decomposePar / reconstructPar works by creating pointToProc, faceToProc, cellToProc lists oin decomposition and then running them backwards when I need to reconstruct the data. If you have a topo change in parallel, such lists are meaningless because there are new cells that did not exist when I decomposed the mesh in the first place. To get around this, I have a new tool: reconstructParMesh This one does not rely on decomposition lists but starts "from nothing" and builds reconstructed...
-
Can you provide a bug fix?
-
Cannot reproduce. First, etc/controlDict is no longer read: this was eliminated by Martin Beaudoin a while back. If you wish to change it on a per-case basis, edit system/controlDict in your case and add eg: InfoSwitches { allowSystemOperations 1; } I am working with the cavity tutorial and as I change it, it allows/disallows the dynamic code: sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN). allowSystemOperations : Allowing...
-
dynamicCode functionality
-
Cannot reproduce. First, etc/controlDict is no longer read: this was eliminated by Martin Beaudoin a while back. If you wish to change it on a per-case basis, edit system/controlDict in your case and add eg: InfoSwitches { allowSystemOperations 1; } I am working with the cavity tutorial and as I change it, it allows/disallows the dynamic code: sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN). allowSystemOperations : Allowing...
-
[foam-extend-4.1]: parallel cases crash when GAMG is selected for pEqn
-
commit 196399ef6ac61aeff40f752daf53b83d59191171
-
[foam-extend 4.1] MPI bug with GAMG solver for pressure (simpleFoam, but may be others)
-
commit 196399ef6ac61aeff40f752daf53b83d59191171
-
[foam-extend-4.1]: parallel cases crash when GAMG is selected for pEqn
-
Reproduced and fixed. Non-blocking comms require a barrier
-
Two bugfixes determined during package building
-
SIGSEGV with mutliple immersed boundary patches
-
Hi, I have re-enabled support for multiple IB patches. Apologies, Inno has done this a while back, but in the heat of debugging I have removed it in error. Please try the latest master branch to test it. I have also included your case as a tutorial example of multiple interacting IB-s. Truth be said, I was not sure if this would work, but it does! Many thanks for the contribution. Adding an option to createPatch to keep empty patches is fine by me - would you like to do the coding, since it is trivial?...
-
Possible bug cyclicGgi
-
Not a bug. Your problem is the mixing plane, not cyclic GGI. If you replace the mixing plane with overlapGgi, the case runs fine without any conservation issues. With a mixing plane, the non-orthogonality correction across the mixing plane interface is not treated, for stability reasons. In your case, you have a full tet mesh for both channels and the non-orthogonality is extreme. The case was decently set up - you got both the cyclic GGIs and mixing plane right. I assume this is a strip-down of...
-
Based on your bug report, I have nothing I can look at, nor can I reproduce the error to check. You did not upload the geometry, log files, mass flow check (what is your continuity error?). I run this every day and "it works for me". Can you provide further info?
-
Suppress Gcc-8 warnings
-
fixed wrong usuage of `find` in `etc/getVariables.py`
-
Bugfix for the testHarness runFunctions
-
Update the compilation of the nextRelease branch under macOS
-
Reverting to old (correct) consistency faceU calculation
-
Better overset assembly controls in validation suite case
-
Consistent velocity reconstruction with moving meshes
-
Additional overset fringe strategy based on cutting patches
-
Updates to fvcReconstruct and Overset include files
-
DLB and AMR fixes and additional developments
-
BUGFIX: View factor smoothing now takes into account reciprocity condition
-
BUGFIX: call to completeAssembly in wrong place
-
STYLE: More meaningful error message when call to setFluxRequired is needed
-
critical bug in getRefCellValue function
-
64-bit label bugfix for refinement utility of dynamicMesh
-
Thank you. The reason for previous delays was a hardware failure on the merge/test server. SHould be replaced by the end of the week.
-
64-bit label bugfix for refinement utility of dynamicMesh
-
Small update to solutionControl's interface
-
Bugfixes and improvements in DLB and AMR
-
gcc8 compliance improvments
-
Why so many changes - all that is needed is the label fix in the last function? There is no problem setting a ref cell next to special patches. Can you comment?
-
BUGFIX: Compile WM_LABEL_SIZE=64
-
Merged elsewhere
-
Bugfix and improvement in interpolateXY function that returns a field
-
-
Included elsewhere
-
Wrong dimensions on creation of zero geometric field
-
Incorrect base class method override in sixDoFRigidBodyDisplacementPointPatchVectorField
-
Incorrect base class method override in sixDoFRigidBodyDisplacementPointPatchVectorField
-
Cummulated fixes Henrik Rusche
-
Parallel bugfix and improvement in multi-region overset
-
Please check - it is to do with the mean in the suitability criterion. Get back to me.
-
Improvement in protectedInitialRefinement
-
GCC8 compatibility improvments
-
BUGFIX: Compile WM_LABEL_SIZE=64 (final)
-
Cumulative development and fixes
-
Bugfix related to variable time step on deforming meshes using backward scheme
-
Another simple but useful overlap assembly strategy for overset
-
BUGFIX: Fixed missing dependency in Windows compilation
-
Added mapping methods to point patch vector fields that have type pointField 'p0_' member
-
Added mapping methods to point patch vector fields that have type pointField 'p0_' member
-
PLB with particles + accumulated bugfixes/backports
1 >