Segfault when attempting PickByGlobalZone(...,vars="fieldname",do_time=1) on a ucdmesh

[nDimensionalSpace]

Describe the bug

Behavior seems consistent between n_processes=1 (for which my script uses engine_ser) and n_processes>1, and between GUI and python interfaces. Leaving off "vars" keyword does not change the result. Leaving off the "do_time" keyword yields a python "TypeError" (which may or may not be as expected). I will note that the analogous call to PickByGlobalNode works as expected.

Helpful additional information

• Did VisIt crash: Yes
• Did you get wrong results: No

To Reproduce

GUI screenshot:

python screenshot:

Expected behavior

Correct results to be returned (possibly including data of any necessary length to represent however many data states a given mesh entity actually exists in), similar to how PickByGlobalNode works.

Attachments

I can share the python script and/or the data on the RZ, as necessary.

Desktop

• OS and version: toss4
• VisIt Version: 3.3.3
• Server info (if applicable): rzwhippet

[nDimensionalSpace]

Ok, so, I have found an interesting dependence; the segfault seems to happen when I write the data into a sufficiently high number of Silo files . . . When I write into 4 silo files, everything works fine, but when I write into 8 silo files, the segfaults happen. As far as I can tell, the element global IDs are being written into Silo independent of the number of files the dataset contains.

[markcmiller86]

Ok, so, I have found an interesting dependence; the segfault seems to happen when I write the data into a sufficiently high number of Silo files . . . When I write into 4 silo files, everything works fine, but when I write into 8 silo files, the segfaults happen. As far as I can tell, the element global IDs are being written into Silo independent of the number of files the dataset contains.

Hmmm...you mean the number of files used for any single timestep, correct? Hmm...how many processors are you using in VisIt when trying these 4 and 8 silo file cases? If you change the number of processors, does that change behavior?

[nDimensionalSpace]

@markcmiller86: Yes, of course, the number of files used for an individual plot state.

My previous statement (a few minutes ago) was regarding the python interface, but I just verified that the GUI behaves consistently (which is reassuring). That is, the segfault is only a function of the number of silo files, at least regarding all of the cases I have checked, as follows:

• num_silo_files<=4, visit using engine_ser or n_processes in {2,4,32}: Things work as expected, and
• num_silo_files in {8,16,32}, visit using engine_ser or n_processes in {num_silo_files,32}: Segfault occurs

Hmmm indeed.

[markcmiller86]

@nDimensionalSpace is it possible to either give @markcmiller86 or @biagas the files on LLNL LC or, better yet, if its possible, attach a sample dataset that manifests the issue here as a gzip'd tarball for example? I understand the latter may not be practical, so give is fine too.

[nDimensionalSpace]

@markcmiller86: It looks like this should work.

GlobalZoneTest_NumSiloFiles4.tar.gz

GlobalZoneTest_NumSiloFiles8.tar.gz