About case of 3D_recovering_sphere

[VaLiuqqq]

When I run the 3D_recovering_sphere case, I find that its 't_step_start' : 400000 is wrong, and when I change it to 0 (without changing anything else), it runs wrong.

It indicates that there is a problem with the upper limit of the array in the source code causing the process to fail

[VaLiuqqq]

How can I modify it to make it work?

[VaLiuqqq]

@sbryngelson could you make the correct version of it?

[wilfonba]

t_step_start should indeed be 0 for this case. As for the out-of-range indices, that's a bug of some sort. Have you tried printing the dimensions of vL_z and the indices being looped over?

[VaLiuqqq]

hello, @wilfonba

I looked at the definition and use of vL_z in /src. No obvious errors were found.

Image error prompt dimension 2. That is, for the dimension definition of vL_z, the variable srarty parameter is involved. But according to m_global parameters.fpp, I don't see any difference between starty and startx in defining parameters.

I did not make a specific printing of it, only from the code definition to see no obvious errors.

[wilfonba]

Well, I'd still try printing the relevant information where it's used. MFC is 40k lines so it's easy to miss things.

[VaLiuqqq]

@wilfonba

OK, looking forward to your correct version.

[wilfonba]

I was asking you to add the print statements yourself and share the results here.

[VaLiuqqq]

@wilfonba

Alright, I tried to add the output of startx, starty, startz to surface tension.fpp, and the result is shown in the figure below.
There is no problem as defined in global parameter.fpp.

And the definition of vL_z (real(kind(0d0)), dimension(startx:, starty:, startz:, iv%beg:, intent(out) :: vL_x, vL_y, vL_z), does not specify what the upper limit of dimension is. So I guess it won't be a question of definition.

In terms of assignment, the assignment steps for variables are different for different recon_dir. For vL_x, its v_vf is j-k-l, for vL_y, its v_vf is k-j-l, and for vL_z, its v_vf is l-k-j. I don't know if the order of v_vf is correct. If this is correct, I do not know what other causes this problem may occur?

[sbryngelson]

this case appears to work fine in pr #664 by @okBrian but he doesn't transform the cases a bit

[wilfonba]

Solution is in #670