https://linen.dev logo
Join Discord
Powered by
# programming
  • t
    The weird thing is the code works just fine with Opt build. It's just that Debug build is picky about it for some reason. I wonder if this could be somehow "working as intended"..
  • o
    just to comment about this, i had the time to test out this approach, and it is not good enought, and the path given is a little bit problematic, as i wanted to have a file on the root of the folder, and with the division of the files on the processors or not in the processors (i mean if run in parallel or in serial) the relative path will be different... and the absolute one will be case dependant so I will do something similar, but instead that will read the values and sed it from the file during the allRun, this looks more robust, simply that is not general and need to change the sed command in different simulations..
  • t
    Does anyone know how to get list of faces of a given cell from 
    fvMesh
    ? Feels like this should be a trivial thing, but I haven't found a way.. CFD-online says 
    mesh.cellFaces()
    but there is no such function. Looks like OF does not need this information, so it is not available. Have to build it yourself.
  • t
  • s
    it is cellFaces()
  • s
    that will give you a list of lists
  • t
    Recent .com or .org does not seem recognize that.. But no biggie, I'll just do it myself. 🤸
  • s
    Copy code
    const labelList& faceOwner = mesh.faceOwner();
  • t
    Indeed you are correct. checkIndex() is called ONLY when FULLDEBUG is true. So, it is a good idea to try compiling and running stuff with OpenFOAM built with 
    WM_COMPILE_OPTION=Debug
    . And sometimes run through valgrind, also.
    Copy code
    template<class T>
inline T& Foam::UList<T>::operator[](const label i)
{
    #ifdef FULLDEBUG
    checkIndex(i);
    #endif
    return v_[i];
}
  • s
    You thought I would lie?
  • t
    NO. What makes you say that?
  • f
    Love it when you thought your biconjugate gradient solver was actually converging compared to deflated conjugate gradient but the whole point of it was that previous people coded the following:
    Copy code
    // Read solver for V
            word solverV
            (
                mesh.solutionDict().solver(V.name()).lookup("solver")
            );

            if(solverV != "deflatedPCG")
            {
// TODO: Read reference values
//                 VEqn.setReference(VRefCell, VRefValue);
                VEqn.setReference(0, 0.0);
            }`
    Which doesnt make physical sense, I do get it when you have 
    p_rgh
    but there is not real reference for it. So I commented it out ran the biconjugate gradient again and no convergence... But some interesting insights
  • f
  • f
  • f
    Some diverging point on the surface
  • t
    mesh there has some weird cells?
  • f
    Not specifically if i recall but it was not converging anyways if i dont set ref value. But indeed must be mesh, even when I made it coarse/fine no difference. When changed coil thickness not yet a solution. When adding a buffer around it to snap on (currently working in that).
  • f
    Do you have any clue why setReference would lead to convergence although to what it converges is ultimately not physical. I think it just takes some reference cell to compute residual but that would generally be very weird. And therefore although said it is converged it technically is not, by means of a reference that doesnt make sense, although what the reference truely means I am not familiar with.
  • t
    IO question: I need to add a feature to smoothMesh which would write and read a bunch of `boolList`s which contain classification of mesh points. The list length is mesh.nPoints(). Reading will be done at first run iteration, writing at writeInterval and last iteration. IOList? Instead of boolList could be some kind of Field. IOField? How to do this? At least not IOList, it does not seem to exist in org. Maybe try to use labelIOList with values 0 and 1, that exists in both org and com 🤦
  • v
    Hello Foamers, recently I'm wokrking on creating a solver with a new classe hierarchy for a DEM like solver with heat transfer i used this definition for my parcels and cloud definitions namespace Foam { typedef ThermoParcel<CollidingParcel<KinematicParcel>> basicThermoParcel; template<> inline bool contiguous() { return true; } } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // #endif and for the submodels i added the paircollsion, wall model and springsliderdashpot for the collisions, i compiled the hole intermediate with these definitions, but when i compile the solver this is the error message that appears /usr/bin/ld.bfd: /home/vvale/OpenFOAM/vvale-7/platforms/linux64GccDPInt32Opt/lib/liblagrangianIntermediateOF7.so: referência não definida para "Foam::WallModel<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::ThermoParcel<Foam::CollidingParcel<Foam::KinematicParcel > > > > > >::dictionaryConstructorTablePtr_" /usr/bin/ld.bfd: /home/vvale/OpenFOAM/vvale-7/platforms/linux64GccDPInt32Opt/lib/liblagrangianIntermediateOF7.so: referência não definida para "Foam::PairModel<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::ThermoParcel<Foam::CollidingParcel<Foam::KinematicParcel > > > > > >::dictionaryConstructorTablePtr_" collect2: error: ld returned 1 exit status the compiler is looking for a hierarchy that is diferent that the one that i defined, and looked at the librarie, and the models are linked for this particular hierarchy, even though is not that the one that i implemented, could someone give a hint of how could i solve this ?? i am compiling the openfoam7 version
  • k
    I'm looking into using a new preconditioner to compare against the typical openfoam preconditioners, however I'm getting having problems trying to replicate openfoam's residual solver process in isolation. Each timestep, I extract the A,b,x^{n},x^{n+1} matrix/vectors of the Ax=b system for iteratively solving and reducing the residual, where x^{n} is the solution vector at the start and x^{n+1} is the converged solution vector after x iterations. I do this for a few nominal tutorial cases with PCG solver and DIC preconditioner and then in python have a fool-proof implementation of the DIC preconditioner, however for the same number of iterations the representative residual is about 3 orders of magnitude higher than the equivalent for the residual reported by openfoam (1e-9 for python DIC vs 1e-12 for openfoam). The trajectories of the C++ implementation of the DIC-preconditioned solver pipeline is the same as the python implementation and several other separate preconditioner pipelines are also about 3 orders of magnitude off from the openfoam residual after the same number of residuals. All of the openfoam cases I looked at intentionally were set to low residual tolerances to get a high number of iterations (~1e2 - 1e3 iterations) for testing. Could the lduMatrix setup in openfoam be causing this discrepancy and if so how could I replicate what openfoam does in isolation for external preconditioner testing?
  • f
    Copy code
    surfaceScalarField Ef
        (
            IOobject
            (
                "Ef",
                mesh.time().timeName(),
                mesh,
                IOobject::NO_READ,
                IOobject::NO_WRITE
            ),
            fvc::interpolate(j0Re) & mesh.Sf() / (fvc::interpolate(sigma))
        );

        Info<< nl << "Calculate applied current distribution" << endl;
        
        // TODO read 'correctNonOrthogonal' from the coil subDict
        while (control.correctNonOrthogonal())
        {
            V0Re.storePrevIter();
            fvScalarMatrix V0ReEqn
            (
                fvm::laplacian // check sign
                (
                    dimensionedScalar("1", dimless, 1),
                    V0Re
                )
            ==
               fvc::div(Ef)
            );

            // TODO ADD REFERENCE LOOKUP
            V0ReEqn.setReference(0, 0.0);
            V0ReEqn.solve(control.subDict(Region::COIL, V0Re.name()));

            if (control.finalNonOrthogonalIter())
            {
                Ef -= V0ReEqn.flux();
            }
            else
            {
                V0Re.relax();
            }
        }
    I have been solving the potentialFlow equation with little bit different variables, However what happends in the solver is that when I run it once it goes 1 times through the loop after which it tries to solve and it gets a floatingPoint error, when I run it again everything works and it goes through the loops and converges. - I have looked at removing 
    fv::div(Ef)
    from the loop interely which still results in the issues, which I think narrows it down to V0Re, I check the initilization and nothing changed. So I am bit clueless on what is going wrong.
  • f
    Copy code
    Run 1:
GAMG:  Solving for V0Re, Initial residual = 1, Final residual = 6.1893306e-09, No Iterations 30
Floating point exception (core dumped)
    Copy code
    Run 2:

Calculate applied current distribution
GAMG:  Solving for V0Re, Initial residual = 1, Final residual = 6.1893306e-09, No Iterations 30
GAMG:  Solving for V0Re, Initial residual = 0.040833635, Final residual = 8.8566906e-07, No Iterations 10
GAMG:  Solving for V0Re, Initial residual = 0.00341274, Final residual = 6.1402001e-08, No Iterations 10
GAMG:  Solving for V0Re, Initial residual = 0.000444691, Final residual = 8.3338828e-09, No Iterations 10
GAMG:  Solving for V0Re, Initial residual = 6.9578259e-05, Final residual = 1.1143398e-09, No Iterations 10
^C
  • f
    The thing I can do to make create a floatingPoint issue is create my custom mapping cellRegionToCellRegion, however this should not be accessed for V0Re. I even made it such that is is a global variable that can be accessed to the region itself, anyways this still resulted in the issue, It is something to do with the resubstitution into the equation something with the assmebly of the 
    fvScalarMatrix
  • t
    I need to program a parallel system for assigning globally unique ID numbers in FOAM. I'm thinking of a system where a master process would be responsible for generating a new free number, and giving them to a process upon request. Sort of like a sentinel from which all processes can ask for a unique ID number, do their work, and come back to ask another ID number, as many times as no more ID numbers are needed. Preferably so that processes don't have to wait for others to complete. Suggestions on how to do this?
  • m
    Is there any upside to having the ID somewhat structured? Otherwise you could just assign the last n digits to represent the process ID and have each process count up from that number e.g. Lets say 3digits for process ID so the first object on process 22 would be 1022
  • m
    Or put the process id at the front
  • t
    That is a possibility, but it implies a hardcoded maximum number of IDs per process. In practice I'm somewhat sure that 1000 IDs per process would suffice.. maybe I'll just do that, much less coding
  • m
    You already allways have a maximum number of IDs per core defined by the data type. I think putting the process identifying numerals at the front would be the smart thing to do because with that you can still count up IDs localy by adding 1 and processor wise by adding the offsett between processors. All you have to do is calculate this offset probanly using a macro like UINT_MAX was it in C I think which defines the Maximum value an uint can store and with that calculate the processor offset. Then the global cell ID would be processorID * offsett + localCellID
  • f
    The dirty way I solved this as my custom solver has some internal issue I am not profound enough to solver was to create a field that was a copy of the initial field without any of the adressing, so only BC + internal field is copied. Using a of the field also resulted in the same issue. Coding wise it is the following:
    Copy code
    volScalarField tempV0Re
        (
            IOobject
            (
                V0Re.name() + "_dbgTemp",
                V0Re.time().timeName(),
                V0Re.db(),
                IOobject::NO_READ,
                IOobject::NO_WRITE
            ),
            V0Re // copy contents + BCs
        );
        globalMesh[COIL].schemesDict().setFluxRequired(V0Re.name() + "_dbgTemp");
    which is a bit nasty, and not user friendly but o well.