ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2018-12-29T13:14:30-05:00https://gitlab.kitware.com/paraview/paraview/-/issues/17202Charts rendering without anti-aliasing with Qt 52018-12-29T13:14:30-05:00Utkarsh AyachitCharts rendering without anti-aliasing with Qt 5See following:
**Qt 4**:
![image](/uploads/63682ca0c6f1953f6c351ba2c81ec7a1/image.png)
**Qt 5**:
![image](/uploads/a06160f48ab40de26ea00a6e068e767e/image.png)
Notice how the lines are more jagged with Qt 5 than Qt 4 (both are ...See following:
**Qt 4**:
![image](/uploads/63682ca0c6f1953f6c351ba2c81ec7a1/image.png)
**Qt 5**:
![image](/uploads/a06160f48ab40de26ea00a6e068e767e/image.png)
Notice how the lines are more jagged with Qt 5 than Qt 4 (both are rendered with OpenGL2 backend).5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/14128excess debug output in servermanager.py2018-08-08T22:26:31-04:00Kitware Robotexcess debug output in servermanager.py**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14128). Further discussion may take place here.**
---
Every process running an in-situ pipeline outputs "use composite data ...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14128). Further discussion may take place here.**
---
Every process running an in-situ pipeline outputs "use composite data append" on every in-situ invocation. This appears to be from debug output being left ON in servermanager.py.
Thanks!
Warren5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/14402Save As Macro broken on Mac2018-08-08T22:26:14-04:00Kitware RobotSave As Macro broken on Mac**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14402). Further discussion may take place here.**
---
The super-awesome feature "Save As Macro" is not working correctly on Mac....**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=14402). Further discussion may take place here.**
---
The super-awesome feature "Save As Macro" is not working correctly on Mac. I can replicate it reliably with the following steps.
1. Delete the ~/.config/ParaView directory.
2. Start ParaView
3. Tools -> Start Trace
4. Tools -> Stop Trace
5. (In the text edit) File -> Save As Macro
Notice in the browser dialog, it is pointing to some directory that is not the appropriate ~/.config/ParaView/Macros. Thus, when you save the file, it does not appear as a macro.
Oddly, if you go to the main ParaView app, select Macros -> Add new macro... then cancel and try the Save As Macro feature, it starts to work.
It would be pretty great if this worked for the SC tutorial.
5.3https://gitlab.kitware.com/paraview/paraview/-/issues/16062Exodus II reader for general polyhedral mesh bug2017-12-12T15:55:22-05:00Kitware RobotExodus II reader for general polyhedral mesh bugEdit -- Summary (details below): Polyhedra face references should be treated as file-scope implicit ids instead of indices into a specific face block.
**This issue was created automatically from an original [Mantis Issue](http://para...Edit -- Summary (details below): Polyhedra face references should be treated as file-scope implicit ids instead of indices into a specific face block.
**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=16062). Further discussion may take place here.**
---
There is a bug in the Exodus II reader. This excellent e-mail thread explains it, and there are two examples referenced that I have included.
Hello,
After discussion with a lot of meshing people, and especially Greg Sjaardema at SNL, the ExodusII lead, I believe there is a bug in the ExodusII reader for the case of arbitrary polyhedra.
Below is an extremely detailed description of the issue, along with a response by Greg explaining what is correct for Exodus. Effectively the current reader expects that there are the same number of face blocks as element blocks in the arbitrary polyhedral format, and this is not the correct data layout of an ExodusII file. I’ve attached two files — example_layout1.exo which is incorrect ExodusII format but works in Paraview, and example_layout2.exo which is correct ExodusII but crashes Paraview.
How/where should this be fixed?
Thanks,
Ethan
—
--------------------------------------------------------------
Ethan Coon
Research Scientist
Computational Earth Sciences -- EES-16
Los Alamos National Laboratory
505-665-8289
http://www.lanl.gov/expertise/profiles/view/ethan-coon
--------------------------------------------------------------
On 03/16/16 12:08, Sjaardema, Gregory D wrote:
The correct representation is closeer to layout 2. The faces are referenced
in a “file implicit” id—basically the same way that elements are referenced
in sideset definitions. (This is what you refer to as “global” numbering,
but I typically use global ids to refer to the ids generated by the maps;
the implicit ordering is the 1..num_entity based on the definition order in
the file). The implicit id relies on the order of the face blocks in the
file and the order of the faces within the blocks.
The primary difference from your layout 2 is that you can have multiple face
blocks. For example, you could define a face block with QUAD faces and then
another face block with your 5-gons (NSIDED) and then your element blocks
could refer to faces from either of the face blocks. You can also have
multiple arbitrary-polygon face blocks.
You are correct that the layout 1 causes invalid meshes due to “duplicated”
faces on the interface between contiguous element blocks. However, exodus
won’t recognize them as duplicated and instead it will refer to two
coincident but distinct faces.
I think much of the confusion comes from the scarcity of documentation on
the exodus arbitrary polyhedra capabilty and that there is typically only a
single test mesh in the test suite and it only has a single element block.
I will try to get some time to generate some additional polyhedra tests and
the documentation, but not sure when I can get to it.
If anyone sees a reason why the multi-face-block-layout-2 does not make
sense, let me know.
..Greg
--
"A supercomputer is a device for turning compute-bound problems into
I/O-bound problems”
From: "Coon, Ethan" <ecoon@lanl.gov>
Date: Wednesday, March 16, 2016 at 10:52 AM
To: "Sjaardema, Gregory D" <gdsjaar@sandia.gov>
Cc: "Garimella, Rao Veerabhadra (LANL)" <rao@lanl.gov>, "Vijay S. Mahadevan
[vijay.m@gmail.com]" <vijay.m@gmail.com>, "Grindeanu, Iulian R.
[iulian@mcs.anl.gov]" <iulian@mcs.anl.gov>, "markmiller@llnl.gov"
<markmiller@llnl.gov>
Subject: [EXTERNAL] ExodusII and arbitrary polyhedra
Hi all, and especially Greg,
I've been working on a project that needs multi-material, arbitrary
polyhedral meshes. After significant discussions with multiple people, I've
discovered a few inconsistencies between how various software packages
assume ExodusII files lay out these types of meshes. Clarification would be
helpful so that these tools can work together!
Throughout I will use the motivating example, for which I've attached two
ExodusII files, one in each layout:
- 2 pentagonal-prisms (i.e. a 7-faced object, where the top and bottom faces
are 5-gons, and all other faces are 4-gons, see
https://en.wikipedia.org/wiki/Pentagonal_prism)
- 2 materials (one prism in each)
ExodusII file layout 1 (format assumed by Paraview/VisIt readers, which I
believe are the same code? Maybe written/maintained by Mark?):
- two element blocks
- two face blocks
- each element block uses a "face id" that is implied by a block-local
numbering of the faces in its face block. So in element block 2, we have:
facconn1 = 1, 2, 3, 4, 5, 6, 7 ;
facconn2 = 1, 2, 3, 4, 5, 6, 7 ;
fbepecnt1 = 5, 5, 4, 4, 4, 4, 4 ;
fbepecnt2= 5, 5, 4, 4, 4, 4, 4 ;
Effectively each of these are indices into their BLOCK list of faces.
ExodusII file layout 2 (format assumed by MSTK, written/maintained by Rao):
- two element blocks
- one or more face blocks
- each element block uses a "face id" that is implied by a global numbering
of the faces in all face blocks. So, in element block 2 we have:
facconn1 = 1, 2, 4, 6, 8, 10, 12 ;
facconn2 = 2, 3, 5, 7, 9, 11, 13 ;
fbepecnt1 = 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4 ;
with one and only one face_blk.
This is often just one and only one face block, where all element block face
lists refer to that same face block.
Note that these two are mutually exclusive -- meshes built in layout 1 crash
MSTK and meshes built in layout 2 crash Paraview/VisIt.
I have a bit of an opinion here. The former may seem natural, in the sense
that each element block has its own faces, but I think it results in
not-well-posed meshes. In the former, the shared face at the interface of
the two materials is listed twice -- it must exist in both face blocks. To
me, the former is a specification for two independent (non-connected) meshes
that share a boundary -- the boundary face is duplicated. It should be
valid Exodus, but it should not refer to a topologically connected mesh. It
is geometrically, but not topologically, degenerate. This is useful for
things like fault modeling, where the domain really is a "punctured" domain
and boundary conditions may be applied on both faces, independently. This
should be distinguished from the typical case, where these are two layers in
the same mesh, and there is only one face on the interface.
The second recognizes that faces, like nodes, which are globally listed in a
single block, are the interface between blocks, and they do not belong to
either material 1 or material 2. It is both topologically and geometrically
"degenerate" in the sense that both elements point to the same face.
Greg, can you weigh in here with your thoughts on which, or neither, is
"correct?" And can a decision be made so that MOAB, Paraview, MSTK, and
VisIt can all work with the same format? Anyone else have comments/thoughts
on this? Is there anyone else that might care about this answer?
Thanks,
Ethan
5.3David ThompsonDavid Thompsonhttps://gitlab.kitware.com/paraview/paraview/-/issues/15640Trace: doesn't save scalar bar position changes2017-11-30T11:38:00-05:00Kitware RobotTrace: doesn't save scalar bar position changes**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15640). Further discussion may take place here.**
---
+ Start ParaView
+ Start Trace
+ Wavelet, Apply
+ Color by RTData
...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15640). Further discussion may take place here.**
---
+ Start ParaView
+ Start Trace
+ Wavelet, Apply
+ Color by RTData
+ Interact with the scalar bar to move its position.
+ Stop Trace
Trace doesn't save the fact that the scalar bar was moved.5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/15868ResetCamera creates bad python2017-11-22T15:14:21-05:00Kitware RobotResetCamera creates bad python**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15868). Further discussion may take place here.**
---
Having a ResetCamera between two filters makes the first filter non vi...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15868). Further discussion may take place here.**
---
Having a ResetCamera between two filters makes the first filter non visible. I created a trace as follows, and will attach said trace. I will add a comment where the bad ResetCamera is.
* ParaView 4.4.0, local server, Windows.
* Start trace recorder.
* Wavelet. Apply.
* Contour. 100. Apply.
* Turn visibility of the contour off.
* Reset
* Contour. 200. Apply.
* Stop trace. Save this trace.
* Reset Session.
* Tools/ Python Shell/ run this trace.
Also relates to paraview/paraview#160055.3Shawn WaldonShawn Waldonhttps://gitlab.kitware.com/paraview/paraview/-/issues/16825Support reading file series are a multiblock instead of a time series2017-11-21T16:32:00-05:00Utkarsh AyachitSupport reading file series are a multiblock instead of a time seriesSometimes a file series (e.g. a STL file series) is a collection of blocks, rather than timesteps. We need to support treating them as a multiblock dataset instead of a time series.
Sometimes a file series (e.g. a STL file series) is a collection of blocks, rather than timesteps. We need to support treating them as a multiblock dataset instead of a time series.
5.3Shawn WaldonShawn Waldonhttps://gitlab.kitware.com/paraview/paraview/-/issues/16988Enable FXAA by default in ParaView2017-11-21T16:31:58-05:00Utkarsh AyachitEnable FXAA by default in ParaView5.3Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/17028PVD files pointing to .pvtu files with multiple pieces are not read correctly...2017-11-21T16:31:57-05:00W. Alan ScottPVD files pointing to .pvtu files with multiple pieces are not read correctly on parallel remote serverWhen you have a .pvd file, which has time data and calls a pvtu file per timestep, and these pvtu files point to numerous .vtu files, ParaView acts differently remote server than local server.
* Local server version of ParaView. tr...When you have a .pvd file, which has time data and calls a pvtu file per timestep, and these pvtu files point to numerous .vtu files, ParaView acts differently remote server than local server.
* Local server version of ParaView. tried with 5.1.2 and older version of 5.2.0 master. Linux.
* Open file rodcylinder.pvtu from the dataset rodcylinder. (I will give this to Utkarsh).
* Information tab. Note that we have 61343 cells.
* Remote server. I used 16 ranks, but I bet it shows with 1 or 2. Linux.
* Open file rodcylinder.pvtu from the dataset rodcylinder.
* Information tab. Note that we have 43218 cells. Only the first of the two .vtu files were read!5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/15458Tiff stack reader, Custom Data Spacing default is wrong2017-11-21T16:31:55-05:00Kitware RobotTiff stack reader, Custom Data Spacing default is wrong**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15458). Further discussion may take place here.**
---
* Please change the Custom Data Spacing default to be the same, either...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15458). Further discussion may take place here.**
---
* Please change the Custom Data Spacing default to be the same, either 1,1,1 or defaultX, defaultY, defaultX (assuming you don't have a Z in a tiff stack!).
OR
* Enable the properties save/ restore state on the Properties (tiffs) section of the Properties tab.5.3Berk GeveciBerk Gevecihttps://gitlab.kitware.com/paraview/paraview/-/issues/17023Warp Scale Factor should default to 12017-11-21T16:31:54-05:00Kenneth MorelandWarp Scale Factor should default to 1The Warp By Vector and Warp By Scalar filters each has an option named Scale Factor that scales the displacement by a multiplier. The initial value in the properties panel is set to some odd value based on the bounds of the data and scal...The Warp By Vector and Warp By Scalar filters each has an option named Scale Factor that scales the displacement by a multiplier. The initial value in the properties panel is set to some odd value based on the bounds of the data and scale of the displacement field (I guess). This makes absolutely no sense.
Displacement vectors are almost always defined in spatial units. Thus, the only default that makes sense is 1.5.3Shawn WaldonShawn Waldonhttps://gitlab.kitware.com/paraview/paraview/-/issues/15887Resample with dataset doesn't work with time2017-11-21T16:31:54-05:00Kitware RobotResample with dataset doesn't work with time**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15887). Further discussion may take place here.**
---
The Resample with dataset filter doesn't work correctly over time. He...**This issue was created automatically from an original [Mantis Issue](http://paraview.org/Bug/view.php?id=15887). Further discussion may take place here.**
---
The Resample with dataset filter doesn't work correctly over time. Here is how to replicate. I will send dataset to Utkarsh.
* Dataset is Resample-Cone-DoNotRelease. This has two files, donor.g and recipient.g.
* Linux, 5.0.0-RC2, local server.
* Timestep 0.
* (If desired, but not necessary, Edit/ Settings/ Clamp and update every timestep).
* Open donor.g. All vars on. Apply.
* Open recipient.g. All vars on. Apply.
* Filter/ Alphabetical/ ResampleWithDataset.
** Input == donor.g
** Source == recipient.g
** OK
** Turn on Pass Cell Array
** Turn on Pass Point Arrays
** Turn off Compute Tolerance. 1e-3.
** Apply.
* Paint by TEMPK.
Lets look at our data.
* Turn visibility off for ResampleWithDataset.
* Turn visibility on for donor.g.
* (Rescale to datarange, there is a weirdness here.)
* Move forward a few timesteps, one at a time. Timestep 0 - Min is about 293.9, max is 293.9. Timestep 1 - min is 294.0, max is 294.4
Now, we can see the bug.
* Turn visibility off for donor.g.
* Turn visibility on for ResampleWithDataset.
* Back to time 0. Min is 0, max is 293.9. Not sure if this is correct.
* Forward to time 1. Min is 0, max is 293.9. This is wrong.
Basically, Rescale with Dataset isn't updating as time is changing.
(Note to me - Trevor, blade.)
5.3Sujin PhilipSujin Philiphttps://gitlab.kitware.com/paraview/paraview/-/issues/16892Broken connectivity of plot data2017-11-21T16:31:54-05:00Utkarsh AyachitBroken connectivity of plot data(from @DennisConklin)
>
I have made up an example of this and in the process have gained some insight as to why it happens, and possible ways to avoid it in the future. Attached is a powerpoint to show it, a data file and a state f...(from @DennisConklin)
>
I have made up an example of this and in the process have gained some insight as to why it happens, and possible ways to avoid it in the future. Attached is a powerpoint to show it, a data file and a state file to play with.
[Broken_Connectivity_of_Plot_Data.pptx](/uploads/06733f5aa39bb1b73e0d2b3d72ca4d07/Broken_Connectivity_of_Plot_Data.pptx)
[ring.e](/uploads/866e16b7149c8a6f177687e0f20e8a62/ring.e)
[PlotData.pvsm](/uploads/98acd122fb9aea1b8e5f242e27c468e1/PlotData.pvsm)5.3Shawn WaldonShawn Waldonhttps://gitlab.kitware.com/paraview/paraview/-/issues/16964ColorBy function does not manage color legend2017-11-21T16:31:54-05:00Kenneth MorelandColorBy function does not manage color legendWhen you are changing the field variable you are coloring a mesh by in the GUI, the scalar bar annotation is updated to give you a color legend with the displayed field. However, when you use the Python `ColorBy` function, which is suppo...When you are changing the field variable you are coloring a mesh by in the GUI, the scalar bar annotation is updated to give you a color legend with the displayed field. However, when you use the Python `ColorBy` function, which is supposed to set up the coloring in the same way as the GUI, the color legend is not updated. To replicate, do the following:
1. Load disk_out_ref.ex2. Turn on all variables. Apply.
2. Open the Python Shell.
3. Type the command
```
ColorBy(GetRepresentation(), ('POINTS', 'Pres'))
```
The points get colored correctly, but the color bar is not changed to the new coloring. If the view had a color bar in the view before calling `ColorBy`, it sticks around after the colors change, which makes it hard to get rid of. The correct behavior is to get rid of color bars that are not used anymore and add the one that is.5.3https://gitlab.kitware.com/paraview/paraview/-/issues/17128quadratic tetrahedra failing with ghost cell generation2017-11-19T19:27:21-05:00W. Alan Scottquadratic tetrahedra failing with ghost cell generationI have a dataset that is failing with ghost cell generation. This is true for D3, Ghost Cell Generation, and Extract Surface. Ken and my speculation is that this case is either not being caught, or needs to be added.
Test as follows...I have a dataset that is failing with ghost cell generation. This is true for D3, Ghost Cell Generation, and Extract Surface. Ken and my speculation is that this case is either not being caught, or needs to be added.
Test as follows:
* Linux, 5.1.2, remote server. I am using 8 ranks.
* Open the spread file hollowSphere_fieldVars.e.48. Apply. (This dataset looks like the ice layer of Europa or a pressure vessel.).
* D3 or Ghost Cell Generator. Apply.
* Change Opacity to 0.2. Notice the processor boundaries.
Now, to show it work correctly, do the following:
* Linux, 5.1.2, remote server. I am using 8 ranks.
* Open the spread file hollowSphere.g.48. Apply. (This dataset looks like the ice layer of Europa).
* Tesselate. Apply.
* D3 or Ghost Cell Generator. Apply.
* Change Opacity to 0.2. Notice the processor boundaries are gone.
I will give the dataset to Utkarsh. It is UUR.
I need either this bug fixed (this one preferrably) or #17137 and #17136 5.3Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://gitlab.kitware.com/paraview/paraview/-/issues/17145Variables disappear on extract selection.2017-11-19T19:27:21-05:00W. Alan ScottVariables disappear on extract selection.A bug from a user. I will give the dataset to Utkarsh. (Note to self - workstation, mst..., cylinder_a_v3.0a.5.e.) (Note to Utkarsh, same dataset as #17081. Same restrictions apply.)
* ParaView master, local server, Linux.
* This d...A bug from a user. I will give the dataset to Utkarsh. (Note to self - workstation, mst..., cylinder_a_v3.0a.5.e.) (Note to Utkarsh, same dataset as #17081. Same restrictions apply.)
* ParaView master, local server, Linux.
* This dataset has three vectors of interest - Q_XX, Q_YY and Q_ZZ, which are orthogonal to each other.
* Read data, all vars on, apply.
* Select one cell. Extract Selection. Apply. Now, I have one cell to play with.
Notice that cell variable Q_XX has disappeared. It doesn't show up as a color to paint with, or in the Information tab. This is a bug.5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/17155If server dies during filter execution, the "Save State" prompt is not useable.2017-11-19T19:27:21-05:00Utkarsh AyachitIf server dies during filter execution, the "Save State" prompt is not useable.Try this:
1. Connect ParaView to pvserver (single rank is fine)
2. Create `Programmable Source` with the following script:
```python
import sys
sys.exit(1)
```
3. Apply
We're simulating a server crash here. On **Apply**, the se...Try this:
1. Connect ParaView to pvserver (single rank is fine)
2. Create `Programmable Source` with the following script:
```python
import sys
sys.exit(1)
```
3. Apply
We're simulating a server crash here. On **Apply**, the server will exit and you should get the following prompt
![image](/uploads/c3fcda5f38ae81603665b9bb2be5fc43/image.png)
However the dialog is not usable! One cannot click on any of the buttons!
Now try this:
1. Connect to pvserver (1 rank).
2. Just `Ctrl-C` to kill the pvserver processes.
This time the same dialog pops up, but is usable. I can click on it to save state etc.5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/17235Find Data dialog is very slow to show up2017-11-19T19:27:21-05:00Utkarsh AyachitFind Data dialog is very slow to show upSteps:
1. Start ParaView
2. Open **can.ex2**, Apply
3. Using [![image](/uploads/576976e42f0a9f1046d96c8cab20f4e2/image.png)](*), create a selection on the block.
4. Now hit **v** to show the Find Data dialog -- it takes a long time t...Steps:
1. Start ParaView
2. Open **can.ex2**, Apply
3. Using [![image](/uploads/576976e42f0a9f1046d96c8cab20f4e2/image.png)](*), create a selection on the block.
4. Now hit **v** to show the Find Data dialog -- it takes a long time to show up.5.3Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/16965Document the --mesa-llvm and --mesa-swr command line arguments2017-11-19T19:27:20-05:00W. Alan ScottDocument the --mesa-llvm and --mesa-swr command line argumentsSomehow, document the --mesa-llvm and --mesa-swr command line arguments when they exist. Preferably, this would be the command line --help. As a fallback (that I don't like), do so on the wiki.Somehow, document the --mesa-llvm and --mesa-swr command line arguments when they exist. Preferably, this would be the command line --help. As a fallback (that I don't like), do so on the wiki.5.3Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/paraview/paraview/-/issues/17077*.pvsm files not being shown in `Load State` dialog2017-11-19T19:27:20-05:00Utkarsh Ayachit*.pvsm files not being shown in `Load State` dialogSee the images below. The `state.pvsm` file doesn't show up until I choose `All files(*)`.
![image](/uploads/34f19e7a011f1f4aa558e69074de53c4/image.png)
![image](/uploads/f0a9e8a2b6e173cef2c1651072013c30/image.png)See the images below. The `state.pvsm` file doesn't show up until I choose `All files(*)`.
![image](/uploads/34f19e7a011f1f4aa558e69074de53c4/image.png)
![image](/uploads/f0a9e8a2b6e173cef2c1651072013c30/image.png)5.3Shawn WaldonShawn Waldon