Skip to content

Eric

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • in reply to: Is that a typo in olb source code #4700
    Eric
    Participant

    Dear Mathias,

    Thanks! I’m glad to help.

    Best regards,
    Eric

    in reply to: Is that a typo in olb source code #4695
    Eric
    Participant

    Dear Mathias,

    Sorry I don’t understand.

    What I know from function olb::BlockGeometryStatistics3D< T >::getType is that discreteNormal determines one boundary node’s type and normal direction. The type of boundary node is defined by discreteNormal[0], e.g. in D3Q19

    discreteNormal[0] = 0 means the node lays on faces and has 6 types;
    discreteNormal[0] = 1 means external corner node and has 8 types;
    discreteNormal[0] = 2 means internal corner node and has 8 types;
    discreteNormal[0] = 3 means external edge node and has 12 types;
    discreteNormal[0] = 4 means internal edge node and has 12 types;

    And in olb::BoundaryConditionInstantiator3D< T, DESCRIPTOR, BoundaryManager >::addVelocityBoundary, we add velocity boundary condition in respect to their types.

    If my understanding above is correct, could you please talk more about why we need a special treatment for InternalCornerPNP (discreteNormal=[2,1,-1,1]) only?

    Best regards,
    Eric

    in reply to: Is that a typo in olb source code #4693
    Eric
    Participant

    Dear Mathias,

    I’m using the newest version, i.e. version 1.3-1.

    In file /src/boundary/boundaryInstantiator3D.h

     580           else if (discreteNormal[0] == 2) {
      581             if (discreteNormal[1] == 1 && discreteNormal[2] == 1 && discreteNormal[3] == 1) {
      582               addInternalVelocityCorner<1,1,1>(iX,iY,iZ, omega);
      583             }
      584             else if (discreteNormal[1] == 1 && discreteNormal[2] == -1 && discreteNormal[3] == 1) {
      585               addExternalVelocityCorner<1,-1,1>(iX,iY,iZ, omega);
      586             }

    In line 585 the function

    addExternalVelocityCorner<1,-1,1>(iX,iY,iZ, omega);

    should be

    addInternalVelocityCorner<1,-1,1>(iX,iY,iZ, omega);

    Thank you,
    Eric

    in reply to: MPI failed with 12 cores #4531
    Eric
    Participant

    Hi Adrian,

    Thank you for your reply! The program works totally fine now.

    Best regards,
    Eric

    in reply to: MPI failed with 12 cores #4501
    Eric
    Participant

    Hi Mathias,

    When will the next release be available? If easier, could you please briefly explain how to fix the bug? I’m running some cases on the cluster but facing the same problem. With OpenMP (shared-memory) it is okay but MPI (distributed-memory) failed.

    Best regards,
    Eric

    in reply to: Create new boundary condition #2905
    Eric
    Participant

    Dear Mathias,

    Thanks for your prompt reply!

    Sorry I didn’t make myself clear. The top and bottom boundary has Ux predescribed (dirichlet bc) and dUy/dy=0 (neumann bc) so I guess it is actually a mxied boundary condition. By pressure boudary condition I guess the velocity gradient at all directions is 0 (exactly neumann type bc). Is there any method not to force dUx/dy=0?

    Best regards,
    Eric

    in reply to: Glitches around cylinder boundary layer #2902
    Eric
    Participant

    Hi Marc,

    Thanks for your reply.

    However, the bounce-back condition doesn’t seems to work. Are these strips around the cylinder reasonable in simulation? I mean, how do these strips and glitches arise in the vorticity contour?

    I tried SmagorinskyBGK and SmagorinskyMRT as well. It seems these glitches can be tuned somewhat by adjusting Cs but they cannot be fully diminished. Also, at very high Re (50,000 in this case), there are upstream vortex formed in front of the cylinder, as can be show in the following plot:
    [img]https://imgur.com/a/WSpVwEs[/img]

    Best regards,
    Eric

    in reply to: Glitches around cylinder boundary layer #2893
    Eric
    Participant

    Hi Marc,

    – The boundary condition around the cylinder is bouzidi boundary condition.
    – Both BGK and MRT solver are applied and glitches are found in both of them.
    – The charLatticeVelocity is set equal to dx = 0.01, which mean the max Mach number should be 0.01/Cs = 0.0173 if I am not mistaken.

    I am now testing it with resolution 200 but I am worried that if I wanna to simulate higher Reynolds number, increasing resolution will increase computational cost to a great degree.

    Best regards,
    Eric

    in reply to: mrtCollision operator in OpenLB #2881
    Eric
    Participant

    Dear Mathias,

    Thank you very much for you explanation!

    Best regards,
    Eric

    in reply to: Initialize at Equilibrium #2832
    Eric
    Participant

    Hi Albert,

    You are right. I made a mistake when setting the uF.
    Thank you for the swift reply!

    Best regards,
    Eric

    in reply to: Local Refinement for multi-block approach #2830
    Eric
    Participant

    Dear Robin,

    Thank you very much for your reply! The local grid refinement would be really helpful for strong turbulence computation as high resolution will take quite long computation time. I’m happy to hear that you are now building this feature and I’m looking forward to see this new function!

    Best regards,
    Eric

Viewing 11 posts - 1 through 11 (of 11 total)