https://linen.dev logo
Join Discord
Powered by
# programming
  • j
    can be good because it means you can get more done but also can be an issue if it gets in the way of things or otherwise causes problems
  • p
    if i had to do this for work, in a way you could argue all above is good if work does not feel like work. but on the other hand, the addictive and all consuming nature of it has some kind of a drug like quality, where i question if the activity of coding/programming itself has some serious unhealthy side effects where it can take over your whole life (in a sense) and hence you become some sort of a zombie like character staring at syntax all day. sure your employer will be delighted (if you do this professionally) but is it healthy for the individual. its a complicated question. maybe one could phrase it in a different way or express it better then i can.
  • j
    no, this isn't some weird property of programming
  • j
    it's just normal ADHD hyperfocus and it has natural limits
  • j
    the only time I've heard of someone's life being consumed by programming was Terry Davis and he had schizophrenia, and believed he was writing code designed by god, or something like that. He would look at words from a random word generator he made and interpret them as signals of god's intention for him.
  • j
    He made a whole operating system from scratch called TempleOS
  • j
    it's actually really cool
  • j
    but like
  • j
    made possible by schizophrenia lol
  • f
    Currently working on verifying my CHT with a richard bénard simulation (the solver is not as in a boussinesq approximation, but fully compressible) although the pressure variations are 0. This is because my solver later will need large temperature variations. When verifying I am going for a Gr = 10^3, Ra = 7.1e-2 Using Pr = 0.71, beta = 0.01 (as I simulate ideal gas, from 100 to 99 K), Cp = 1000 (stabilization), P = 1e5, M = 8.314 g/mol, rho = 1 (solution of the paramters). dynamic viscosity = 0.001. For the wanted Gr I find g = 0.1 This leads to alpha = 1.40845e-3 kappa_f = 1.40845 I use Kr = kappa_s/kappa_F = 10 kappa_s = 14.0845 I initialize the temperature field already with T(t=0) = 100 -5/6 x Then I run my simulation, I calculate the heatFlux on the CHT wall with. Finally finding a Nu = 1.5, although it should be 1.04
  • f
    The heat flux is calculated as:
    Copy code
    void Foam::chtPimpleApp::Manager::write() const
{
    Region_FLUID::Storage& storage = regions().region_FLUID().storage();


    const volScalarField& T     = storage.thermo().T();
    const volScalarField& kappa = storage.Kappa();

    forAll(T.boundaryField(), patchI)
    {
        const fvPatchScalarField& Tpatch = T.boundaryField()[patchI];

        if (isType<solidWallMixedTemperatureCoupledFvPatchScalarField>(Tpatch))
        {
            const fvPatchScalarField& Tpatch = T.boundaryField()[patchI];

            // Thermal conductivity at this patch
            const scalarField& kappaPatch = kappa.boundaryField()[patchI];

            // Compute per-face heat flux: q = kappa * (gradT · n) * faceArea
            scalarField heatFluxPatch = kappaPatch * Tpatch.snGrad() * Tpatch.patch().magSf();

            surfaceScalarField heatFlux
            (
                IOobject
                (
                    "heatFlux",       
                    this->time().timeName(),  
                    T.mesh(),       
                    IOobject::NO_READ,
                    IOobject::AUTO_WRITE
                ),
                T.mesh(),            
                dimensionedScalar("zero", dimensionSet(1,0,-3,0,0,0,0), 0.0) // initialize all faces to 0
            );

            heatFlux.boundaryField()[patchI] = heatFluxPatch;

            heatFlux.write();
        }
    }
}
  • t
    I learned today that the "normal" optimized version of OF (
    WM_COMPILE_OPTION=Opt
    ) allows access beyond end of 
    UList
    , but the debug version (
    WM_COMPILE_OPTION=Debug
    ) does not and raises error like the one below. Does anyone know why the optimized UList behaves differently than the debug version? This means that one should always try to compile and and run on both Opt and Debug versions to reveal hidden bugs.
    Copy code
    --> FOAM FATAL ERROR: 
index 78000 out of range 0 ... 76799

    From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::Vector<double>; Foam::label = int]
  • s
    Bounds checking is only performed for const-qualified objects
  • t
    So, why is the behavior different in Opt vs. Debug builds?
  • s
    I would assume there is a bounds checking when the Debug flag is active
  • s
    youll have to deep dive in the code my friendo
  • s
    otherwise use the classic List<>
  • s
    if you want bounds checkking always
  • t
    Ok thanks. Unfortunately, the choice is not mine, this happens for 
    Foam::fvMesh::Cf()
    and many more of base fvMesh functions when I try to access the values on patch faces..
  • 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?