coastal_ike_shinnecock_atm2sch2ww3 hanging on Orion with Intel compiler #4
Comments
uturuncoglu
changed the title
|
@josephzhang8 @platipodium I track down this issue and compile to code in debug mode. It seems it is crashing with following trace. It is throwing floating point exception from the following line, I am not sure this is related with the model or coupling interface. I'll check the information that goes to SCHSIM but maybe you might have some idea. |
|
@josephzhang8 @platipodium BTW, this is in the initialization and just before everything and it is called in |
|
@josephzhang8 @platipodium Okay. I print out values of Anyway, let me know if you are agree about the issue and the bug. Then, please let me know about solution. I'll try to give initial value to |
|
Th @uturuncoglu . I'll fix this bug. diffm[in,ax] are not used with itur=0, but it's best to init them. |
|
@josephzhang8 Thanks. If you want I could test your fix branch in my end to be sure that it is fixing the issue. After passing this point, there might be another issues that you want to fix. Anyway, it is your call. |
|
@josephzhang8 BTW, I'll also test the code with GNU. Maybe the underlying issue is same with #3. BTW, I am not sure why atm2sch test is working without any issue. Maybe that one is using different options for |
|
Yes we test different compilers regularly to catch potential issues. The fixes are needed no matter what, to make SCHISM robust on all platforms. Thx for working with us! |
|
@uturuncoglu: I've fixed the bug in master version. Can u plz pull? Thx |
|
@josephzhang8 Okay. Thanks. I'll try to run the case with your fix and update you. |
|
@josephzhang8 Okay. The code passed that point but now giving error like following, Here is the line, https://github.com/schism-dev/schism/blob/84866bf95d779a43056db4c8885908bd675010b3/src/Hydro/misc_subs.F90#L6194. I did not debug further but it seems that |
|
@josephzhang8 this might be a bug in cap side. I think that the variable assignments that are used in the following call is wrong, I think this needs to use |
|
@josephzhang8 @platipodium I was looking for the issue related with the |
|
@uturuncoglu: npa=np+npg (resident + ghost). I thought EMSF does not handle ghost zone so the input arrays RSXX0 have a dim of np, and then RSXX etc are used in exchange to get ghost. ns, nsa are # of edges of elements. Wave forces are defined at edges (side centers) due to gradient operator. The arrays in hgrad_nodes() have to be dim of npa (augmented). |
|
@josephzhang8 Yes, we don't have ghost elements anymore. So, we need to adjust the call based on this reality (we might have two version of it one with node based mesh and another for element until we switch element based completely. Anyway, it would be hard for me to understand the logic over there. So, is there any both in your side to look at closely that part of code? If not, I could try to look at but I am not sure who I have the fix since I also need to spend time in other projects. |
|
@uturuncoglu : that routine is basically same as the (well tested) routine used by the internal wave module (WWM), so I think the only potentially errors may be from interface. |
|
@josephzhang8 Okay. So, you think that we don't need to change anything in the routine but maybe add some logic to fill the arrays in a correct way before passing to it. Right? |
|
Hold on... I think I may have found the bug.... |
|
@uturuncoglu I just pushed a new master; can u plz check? Thx! |
|
@josephzhang8 Okay. Let me test. This might still need some fix in upper level to get the required data from import state. |
|
Yes that's the part I'm not sure about. I noticed last time u added some allocatable, target arrays in schism_glbl.F90 |
|
@josephzhang8 I am getting FPE from |
|
@josephzhang8 I think I fixed the issue. The wave related fields looks fine now. I'll do more test and then crate PR in SCHSIM-ESMF repository. Just for your information, here are the changes https://github.com/oceanmodeling/schism-esmf/pull/new/hotfix/wave_stress |
|
@josephzhang8 I run the case and plot rsxx rsyy rsxy |
|
@josephzhang8 So, we might have issue in outputting |
|
I don't see scale bar; maybe SXY is very small? |
|
@josephzhang8 JFYI, i checked the import state for the |
|
@josephzhang8 let me use same scale with the preview and NCL to double check. |
|
@josephzhang8 Okay. I think it is hard to make scale same since SCHSIM is applying some unit conversion I think. The data coming from wave has range of
Anyway, I think this is fine and fix working as expected. I'll also check the GNU issue to see if this fix also handles that case too. |
|
Great to know; thx @uturuncoglu! |
|
@josephzhang8 Joseph, could you please update the document (if needed)? ww3-exports-ocn-3Dwave-terms |
|
@josephzhang8 It is also working with GNU. I will do one last test with GNU and DEBUG mode. It that also pass I'll create PR and maybe we could close two issues in the same time. |
|
gr8! |
|
@pvelissariou1 : I just did that |
|
@uturuncoglu : do u want me to review/merge the PR now? Thx |
|
scratch that... I see the request from u now |
|
@josephzhang8 JFYI, I replied in the PR side. Once this in I am plaining to define two more test in UFS Coastal side one for GNU and one for DEBUG mode to cover different cases. So, we would be sure where are fine with those option in the future. |
|
@josephzhang8 Thank you Joseph. @uturuncoglu After the PR is merged, I guess you will update ufs-coastal as well. I am planning to check all SCHISM related tests. |
|
@pvelissariou1 You could test by checking out master in SCHSIM and https://github.com/oceanmodeling/schism-esmf/tree/hotfix/wave_stress branch in SCHSIM-ESMF side. If we have issue, it would be better to know it before merge. @josephzhang8 maybe we could wait for Takis to perform initial test. |
|
@uturuncoglu , @josephzhang8 Thank you very much both. Ufuk I will check SCHISM as you suggested and we will talk about this on Monday. Hopefully all will be fine. |
|
@mansurjisan to check |
coastal_ike_shinnecock_atm2sch2ww3test case is hanging on Orion with Intel compiler. I also tried to run it on Hercules with Intel and it is passing. So, this could be a system issue but maybe it is linked with #3 and needs to be investigated.The text was updated successfully, but these errors were encountered: