Hi Kai,

can you please also post the output that you get?


Kind regards

Bernd


--
_________________________________________________________________

Bernd Flemisch
IWS, Universität Stuttgart               phone: +49 711 685 69162
Pfaffenwaldring 61              email: [email protected]
D-70569 Stuttgart           url: 
www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/>
_________________________________________________________________
________________________________
Von: DuMux <[email protected]> im Auftrag von Kai Wendel 
<[email protected]>
Gesendet: Dienstag, 2. August 2022 14:55:48
An: [email protected]
Betreff: [DuMux] Fwd: A weird bug in timeloop.hh

Hello,

I am currently implementing a secondorder sequential (Strang sequential) scheme 
for freeflow models, which therefore has two timeloops, as there are two 
sequentially solved subproblems.
It then happens after some time, that the function call advanceTimeStep() does 
not lead to an increase in the member varialbe time_, despite the expression 
time_ += timeStepSize_; is called and timeStepSize_ is definitely not zero.

I checked this by writing the values out to the command line:
    void advanceTimeStep() override
    {
        std::cout << "advanceTimeStep: timeStepSize_ = " << timeStepSize_;
        timeStepIdx_++;
        std::cout << " time_ = " << time_ << std::endl;
        time_ += timeStepSize_;
        std::cout << "time_ = " << time_ << " time_+timeStepSize_ = " << time_+ 
timeStepSize_ << " What is with timeStepSize_: " << timeStepSize_ << std::endl; 
// NOTE: I receive the same value for time_ as before calling time_ += 
timeStepSize_;
        previousTimeStepSize_ = timeStepSize_;

        // compute how long the last time step took
        const auto cpuTime = wallClockTime();
        timeStepWallClockTime_ = cpuTime - timeAfterLastTimeStep_;
        timeAfterLastTimeStep_ = cpuTime;

        // ensure that using current dt we don't exceed tEnd in next time step
        setTimeStepSize(timeStepSize_);
    }
The dumux version used is
commit 79d3057e3ee504ab40d3bc918931ca83fa008481 (HEAD)
in the dumux master branch

I have no idea, what could be the reason for this. Could this be connected to 
the use of the CheckpointTimeLoop class?
Is there a possibility that the varialbe time_ has received some upper limit? 
How can this happen?

Thanks for helping.

Best
Kai Wendel
_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Reply via email to