Issue #2337
wontfix
Responding to http://lists.einsteintoolkit.org/pipermail/users/2020-February/007288.html I had a look at AHFInderDirect (see http://lists.einsteintoolkit.org/pipermail/users/2020-February/007291.html) and found this code (in line 678):
674 if ((my_dont_find_after >= 0 and cctk_iteration > my_dont_find_after) or 675 (my_dont_find_after_time > my_find_after_time and cctk_time > my_dont_find_after_time)) 676 { 677 assert (! AH_data.search_flag); 678 sf_active[surface_number] = 0; 679 } 680 681 // only try to copy AH info if we've found AHs at this time level 682 if (! AH_data.search_flag) { 683 sf_valid[surface_number] = 0; 684 return; 685 } 686 687 // did we actually *find* this horizon? 688 if (! AH_data.found_flag) { 689 sf_valid[surface_number] = -1; 690 return; 691 } 692 693 sf_active [surface_number] = 1;
which to me looks like it has sa but in line 678 where there should be a return statement.
Comments (5)
-
reporter -
reporter -
assigned issue to
-
assigned issue to
-
reporter - changed status to open
-
reporter On closer inspecting this may be correct, but benefit from a comment. Namely, not having a
return
statement in 678 means that (due to theassert
in 677) the code is guaranteed to clearsf_valid
in 683 and return there.Ie the code will mark the surface that was not looked for as invalid.
-
reporter - changed status to wontfix
Works as it should.
- Log in to comment
A bug, but has been there for a long time. Since it will affect the how surfaces are used by existing runs, will be addressed after the ET_2020_05 release and backported if found to not be too disruptive to code relying on the (erroneous) behaviour.