Solar calculator provides wrong sun direction for runtime longer than 24 hours

Summary

When running a transient simulation with Solar Load and sunDirTracking, the solarCalculator returns the wrong sun direction when the runtime goes over 24 hours. The sun trajectory is correct for the first 24 hours, and then stays west for the following days.

Steps to reproduce

Run a case over a total runtime of more than 24 hours, with Solar Load enabled and with an obstacle to generate projected shadows.

Example case

The following case is a simple box with an opaque ceiling and an opaque floor, and transparent sides. The total simulated time is 48 hours. When displaying qr on the ground, the projected shadow of the ceiling on the floor is correct for the first 24 hours (from west to east, as the sun moves from east to west) and wrong for the last 24 hours (stays east, as if the sun rose and set west).

solarCalculator_case.zip

This case solves only the radiation, every other equation is turned off to allow a 1-hour timestep.

What is the current bug behaviour?

The solarCalculator predicts a sun staying west when the runtime goes over 24 hours.

What is the expected correct behavior?

The sun should move from east to west even for runtimes longer than 24 hours.

Environment information

• OpenFOAM version : v2406
• Operating system : Windows 10

Possible fixes

Adding a modulo function at line 95 of solarCalculator.C seems to take care of the issue without any additional effects:

scalar LST = startTime_ + (runTime/3600.0) % 24;

changed the description

added bug community labels

assigned to @Mattijs

Could you test with

const scalar LST = startTime_ + std::fmod(runTime/3600.0, 24);

?

Sure, although I have some experience only with compilation of custom solvers with minor modifications. Should I just compile the whole OpenFoam source code with the edited version of the solarload calculator? Or can I simply compile the radiation folder?

Last one - just change the one line in that source file (solarCalculator.C) and type wmake. Should rebuild only the library.

Noted, thanks, I will report back as soon as possible! In the meantime, if this fixes the issue, how soon can we expect it to make it to the precompiled Windows version? I am only asking because my case will be shared with other users that will have only access to Windows.

The modulo fix works great on OpenFoam v2212 (the issue is identical for both versions, it was simply faster to test with an old custom installation folder than installing the latest version).

mentioned in commit 7f1120f6

resolved by commit 7f1120f6

closed

Btw, many thanks for fix. I've used std::fmod so we get correct behaviour in WM_SP.

Thanks for the quick answer! Can you tell how soon an updated version of the precompiled build for Windows will be available?

mentioned in commit 45e7c4a0