You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the 4ed0688, the ocean dynamic timestep and ocean tracer timestep are both set to 1800s, which is less than the coupler timestep of 3600s. Under this setup, the config runs successfully.
When the dynamic timestep is different from the tracer timestep which is increased to match the coupler timestep (for example, 3600s), the run proceeds as expected. However, if the tracer timestep exceeds the coupler timestep, the run fails with the following error in the access-om3.out,
3 total processes killed (some possibly by mpirun during cleanup)
This is followed by segmentation fault messages in access-om3.err,
[gadi-cpu-clx-2581:855569:0:855569] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[gadi-cpu-clx-2586:3332582:0:3332582] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[gadi-cpu-clx-2582:1539352:0:1539352] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[gadi-cpu-clx-2585:1181885:0:1181885] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[gadi-cpu-clx-2583:3307811:0:3307811] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[gadi-cpu-clx-2581:855544:0:855544] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
...
This suggests that when the tracer timestep exceeds the coupler timestep, it triggers a segmentation fault, likely due to a mismatch in time synchronisation between components.
After a quick discussion with @ezhilsabareesh8 , a possible reason for the failure, as suggested by him, could be related to the fluxes being passed from WW3 to MOM6.
! wave to ocean coupling
if ( associated(IOB%lamult)) then
do j=js,je; do i=is,ie
if (IOB%ice_fraction(i-i0,j-j0) <= 0.05 ) then
fluxes%lamult(i,j) = IOB%lamult(i-i0,j-j0)
else
fluxes%lamult(i,j) = 1.0
endif
enddo ; enddo
call pass_var(fluxes%lamult, G%domain, halo=1 )
endif
I am unsure about this issue, so I'll leave it to you @ezhilsabareesh8 for your input and help.
The text was updated successfully, but these errors were encountered:
In the 4ed0688, the ocean dynamic timestep and ocean tracer timestep are both set to 1800s, which is less than the coupler timestep of 3600s. Under this setup, the config runs successfully.
When the dynamic timestep is different from the tracer timestep which is increased to match the coupler timestep (for example, 3600s), the run proceeds as expected. However, if the tracer timestep exceeds the coupler timestep, the run fails with the following error in the
access-om3.out
,This is followed by segmentation fault messages in
access-om3.err
,This suggests that when the tracer timestep exceeds the coupler timestep, it triggers a segmentation fault, likely due to a mismatch in time synchronisation between components.
After a quick discussion with @ezhilsabareesh8 , a possible reason for the failure, as suggested by him, could be related to the fluxes being passed from WW3 to MOM6.
I am unsure about this issue, so I'll leave it to you @ezhilsabareesh8 for your input and help.
The text was updated successfully, but these errors were encountered: