Giter Club home page Giter Club logo

visit-dav / visit Goto Github PK

View Code? Open in Web Editor NEW
394.0 23.0 110.0 371.89 MB

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data

Home Page: https://visit.llnl.gov

License: BSD 3-Clause "New" or "Revised" License

CMake 1.59% C 75.72% C++ 12.80% Shell 1.15% Objective-C++ 0.01% Perl 0.02% Python 3.83% Batchfile 0.01% QMake 0.01% Java 3.03% CSS 0.01% JavaScript 0.08% HTML 1.32% Mathematica 0.01% Fortran 0.44% Makefile 0.01% Gnuplot 0.01% Awk 0.01% XSLT 0.01% Dockerfile 0.01%
hpc scientific-visualization scientific-computing visualization data-analysis radiuss data-viz python

visit's Introduction

GitHub commit activity GitHub contributors

VisIt

Source code repository for the VisIt Scientific Visualization and Data Analysis Application

Project Website | Nightly Test Status

Documentation

Users Manuals Documentation Status

Getting Help

Developer Resources

License

VisIt is distributed under the terms of the BSD-3 License

All new contributions must be made under the BSD-3 License

See LICENSE and NOTICE for details.

LLNL-CODE-793424

visit's People

Contributors

acbauer avatar aowen87 avatar arsanderson avatar ax3l avatar benjaminjeliot avatar biagas avatar bradwhitlock avatar brugger1 avatar burlen avatar cchriste avatar cessenat avatar cyrush avatar david-camp avatar dpugmire avatar ghweber avatar griffin28 avatar hankchilds avatar harinarayankrishnan avatar iulian787 avatar jameskress avatar jsmeredith avatar justinprivitera avatar markcmiller86 avatar mclarsen avatar pnav avatar probstenhias avatar rrsisneros avatar rusu24edward avatar selbypa avatar spetruzza avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

visit's Issues

Native precision for label plot.

cqid: VisIt00006343cqsubmitter: Hank Childscqsubmitdate: 06/23/05 From Rob Neely's e-mail: Another thing that would be nice is if the label plot and pick function would print out double precision data if that's what's in your data file. It's hard to debug things like symmetry problems that start out small when you can't see all your precision. Modification by KSB 12 July 2005:Changed headline to 'native' precision from 'double'.Removed pick from headline as it is covered by ticket '6112.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 39
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Native precision for label plot.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 4 - High
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00006343cqsubmitter: Hank Childscqsubmitdate: 06/23/05 From Rob Neely's e-mail: Another thing that would be nice is if the label plot and pick function would print out double precision data if that's what's in your data file. It's hard to debug things like symmetry problems that start out small when you can't see all your precision. Modification by KSB 12 July 2005:Changed headline to 'native' precision from 'double'.Removed pick from headline as it is covered by ticket '6112.

Comments:

failure to compile Vs plugin under gcc 8.2

error: could not convert ‘((subBigIndex / ((const VsStaggeredField*)this)->twoPowSubRes) % 2)’ from ‘size_t’ {aka ‘long unsigned int’} to ‘std::valarray’
return (subBigIndex / this->twoPowSubRes) % 2;

I had to edit VsStaggeredField.C to go over the compilation error

I changed

return (subBigIndex / this->twoPowSubRes) % 2;

to

return (subBigIndex / static_cast(this->twoPowSubRes)) % 2;

HTH

Treat all DBs as time varying adversely affecting "-o file"

cqid: VisIt00008432cqsubmitter: Hank Childscqsubmitdate: 01/08/08 I think this is a potential new bug in V1.8.0. Blow away your configs. Start up VisIt and turn on "Treat all DBs as time varying". Save and exit. Now start up VisIt as "visit -o /path/to/globe.silo". The plots list remains greyed out. You have to ReOpen to make a plot. Added, HRC, 2/4/08:Another data point: Gunther noticed that if you open a gzipped Chombo file, this doesn't happen. So involving the ZipWrapper file format affects this.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 22
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Treat all DBs as time varying adversely affecting "-o file"
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:14 pm
Updated:
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008432cqsubmitter: Hank Childscqsubmitdate: 01/08/08 I think this is a potential new bug in V1.8.0. Blow away your configs. Start up VisIt and turn on "Treat all DBs as time varying". Save and exit. Now start up VisIt as "visit -o /path/to/globe.silo". The plots list remains greyed out. You have to ReOpen to make a plot. Added, HRC, 2/4/08:Another data point: Gunther noticed that if you open a gzipped Chombo file, this doesn't happen. So involving the ZipWrapper file format affects this.

Comments:

Add ability to remove host profiles from the list.

cqid: VisIt00008931cqsubmitter: Eric Bruggercqsubmitdate: 06/02/09 The list of host profiles at LLNL is quite long and many users only access a smallnumber of them (e.g. they don't use the Q machine or redrose typically). Barbwould like to remove the ones she doesn't use from the list. She of course canremove them, but the next time she starts up visit, the public ones show up again,because they are in the public config file.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 46
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Add ability to remove host profiles from the list.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 2 - Low
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008931cqsubmitter: Eric Bruggercqsubmitdate: 06/02/09 The list of host profiles at LLNL is quite long and many users only access a smallnumber of them (e.g. they don't use the Q machine or redrose typically). Barbwould like to remove the ones she doesn't use from the list. She of course canremove them, but the next time she starts up visit, the public ones show up again,because they are in the public config file.

Comments:

time arg to CLI's GetMetaData method corrupts correlation behavior

cqid: VisIt00008178cqsubmitter: Mark Millercqsubmitdate: 08/07/07 visit diff makes use of CLI's GetMetaData method. That method takes an optional timestate argument. However, when that argument is provided AND is nonzero, its uses causes all sorts of problems with correlation behavior. To demonstrate the problem, edit visitdiff.py in SyncTimeStates method and comment out the calls to GetMetaData with 'currentTimeState' arg. You will see a difference in behavior between the two cases. The one WITHOUT currentTimeState arg. behaves as expected. The one with behaves very strangely. Nothing is correlated/locked in time. Try runint the diff.py test in tests/databases and you should see the problem.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 41
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: time arg to CLI's GetMetaData method corrupts correlation behavior
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008178cqsubmitter: Mark Millercqsubmitdate: 08/07/07 visit diff makes use of CLI's GetMetaData method. That method takes an optional timestate argument. However, when that argument is provided AND is nonzero, its uses causes all sorts of problems with correlation behavior. To demonstrate the problem, edit visitdiff.py in SyncTimeStates method and comment out the calls to GetMetaData with 'currentTimeState' arg. You will see a difference in behavior between the two cases. The one WITHOUT currentTimeState arg. behaves as expected. The one with behaves very strangely. Nothing is correlated/locked in time. Try runint the diff.py test in tests/databases and you should see the problem.

Comments:

Files with a ton of variables take many minutes to load.

cqid: VisIt00008781cqsubmitter: Brad Whitlockcqsubmitdate: 10/23/08 We know about this issue and there could be another ticket for it but here is a new instance of the problem. Chad Noble gave me a Silo file that takes forever to open. I timed VisIt and the Silo file itself takes 17-30 seconds to open. That's way slow and there are a lot of subdirectories, etc that make the file reading slow. The real problem is that once the file is open, each plot menu takes about 30 seconds to construct due to the large number of variables. Essentially, we're waiting about 20(menus)*30(sec/menu) seconds. I gave up each time since it was too long to wait to open a file. We need to rethink our menus. Where possible, we need to share like menus between plots. We also should consider a way of dynamically creating different levels of the menu on the fly so they get created as we scroll to them. These enhancements, if possible, should greatly speed up menu creation and make file opening more tolerable for these types of files. If menu changes are not possible, we might switch the plot menus to an alternate, more efficient widget above a certain number of variables. It's worth noting that the existing code (albeit somewhat modified) is 10x faster on my Qt4 branch. That's a large improvement but we should also implement other speed improvements.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 33
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Files with a ton of variables take many minutes to load.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 07/20/2010 07:07 pm
Likelihood: 3 - Occasional
Severity: 5 - Very Serious
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008781cqsubmitter: Brad Whitlockcqsubmitdate: 10/23/08 We know about this issue and there could be another ticket for it but here is a new instance of the problem. Chad Noble gave me a Silo file that takes forever to open. I timed VisIt and the Silo file itself takes 17-30 seconds to open. That's way slow and there are a lot of subdirectories, etc that make the file reading slow. The real problem is that once the file is open, each plot menu takes about 30 seconds to construct due to the large number of variables. Essentially, we're waiting about 20(menus)*30(sec/menu) seconds. I gave up each time since it was too long to wait to open a file. We need to rethink our menus. Where possible, we need to share like menus between plots. We also should consider a way of dynamically creating different levels of the menu on the fly so they get created as we scroll to them. These enhancements, if possible, should greatly speed up menu creation and make file opening more tolerable for these types of files. If menu changes are not possible, we might switch the plot menus to an alternate, more efficient widget above a certain number of variables. It's worth noting that the existing code (albeit somewhat modified) is 10x faster on my Qt4 branch. That's a large improvement but we should also implement other speed improvements.

Comments:
I tried sesame.pdb database which often takes a while to load. It opened in about 1520 seconds. But, more impressive was the time to draw a plot after hitting draw button. Pre2.0 versions could take 1520 seconds. 2.0 takes about 12 seconds to display the plot! Thats a big improvement. We considered these performance numbers good enough to call this issue resolved. Great job by Qt4 transition folks!

Localized compactness factor failing in parallel

cqid: VisIt00007930cqsubmitter: Hank Childscqsubmitdate: 03/27/07 Testing every VisIt query in parallel with a sil selection that left processors with no data, the localized compactness factor query caused the engine to crash. So we should fix up this query.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 19
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Localized compactness factor failing in parallel
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 2 - Rare
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007930cqsubmitter: Hank Childscqsubmitdate: 03/27/07 Testing every VisIt query in parallel with a sil selection that left processors with no data, the localized compactness factor query caused the engine to crash. So we should fix up this query.

Comments:

Display documentation in the Query window about what each of the queries does

cqid: VisIt00007714cqsubmitter: Eric Bruggercqsubmitdate: 02/01/07 Display documentation in the Query window about what each of thequeries does. That way, the user is encouraged to explore the window,rather than being daunted by the sheer number of Queries.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 40
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Display documentation in the Query window about what each of the queries does
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 4 - High
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007714cqsubmitter: Eric Bruggercqsubmitdate: 02/01/07 Display documentation in the Query window about what each of thequeries does. That way, the user is encouraged to explore the window,rather than being daunted by the sheer number of Queries.

Comments:

Problem with naming anonymous expression results in execution pipeline.

cqid: VisIt00008610cqsubmitter: Cyrus Harrisoncqsubmitdate: 05/12/08 Open up thinplane.silo, and define the following expression:expr = val4mat(den,1) + val4mat(den,2) Instead of naming the intermediate results "val4mat(den,1)" and "val4mat(den,14)", only one secondary variable is passedto the add expression, "val4mat(den)" and the result ends up being 2 * val4mat(den,1). This is the first time I have run into this behavior, but I believe it could exist elsewhere if constants are used as expression arguments. There is a work around, simply define the two val4mat subexpressions as full expressions, and add these expressions: vfm1 = val4mat(den,1)vfm2 = val4mat(den,2)expr = vfm1 + vfm2

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 50
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Problem with naming anonymous expression results in execution pipeline.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008610cqsubmitter: Cyrus Harrisoncqsubmitdate: 05/12/08 Open up thinplane.silo, and define the following expression:expr = val4mat(den,1) + val4mat(den,2) Instead of naming the intermediate results "val4mat(den,1)" and "val4mat(den,14)", only one secondary variable is passedto the add expression, "val4mat(den)" and the result ends up being 2 * val4mat(den,1). This is the first time I have run into this behavior, but I believe it could exist elsewhere if constants are used as expression arguments. There is a work around, simply define the two val4mat subexpressions as full expressions, and add these expressions: vfm1 = val4mat(den,1)vfm2 = val4mat(den,2)expr = vfm1 + vfm2

Comments:

Scatter plot gets colors wrong when restored from session.

cqid: VisIt00008570cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 03/28/08 Marcel Zemp provided session files and relevant data files.I copied his session files and modified them for ourmachines and local directory. I only investigated the plot using vel_rad asthe x-coordinate. The gist is that the scatter plot is colored red whenrestored from the sessionfile, but when created freshhas lots of green, cyan and blue color. All variables being used for the scatter plot are expressions, and the min/max for the Color variablehave been changed from default. data is is /usr/gapps/visit/bug_data/visit_bug_8570.tar.gz on OCF. From Marcel's email:+Hello, I found a strange bug in Visit that has to do with scatter plot. If you open the attached session file then the colour of the points is not correct. If one then: goes to scatter plots attributes disables the min/max values for the color range apply button enables the min/max values for the color range again- apply button => colours are correct => but min/max values are still 0 Added ESB 4/4/2008: From additional e-mails: Addition: If the plot is in a state where it shows the correct colour with a black background and then tries to swap the background/foreground colours => all points are black (with white background) and I found no way so far to change that.... Ok - a further addition: if I change the sphape into spheres instead of points, change to white background, start the keyframe animation then the colours come back after a few frames and I can even switch now between different background colours and the colours of the points are correct. So there is some wired stuff going on here... but I hope this probably helps to hunt down the bug...

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 30
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Scatter plot gets colors wrong when restored from session.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
cqid: VisIt00008570cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 03/28/08 Marcel Zemp provided session files and relevant data files.I copied his session files and modified them for ourmachines and local directory. I only investigated the plot using vel_rad asthe x-coordinate. The gist is that the scatter plot is colored red whenrestored from the sessionfile, but when created freshhas lots of green, cyan and blue color. All variables being used for the scatter plot are expressions, and the min/max for the Color variablehave been changed from default. data is is /usr/gapps/visit/bug_data/visit_bug_8570.tar.gz on OCF. From Marcel's email:+Hello, I found a strange bug in Visit that has to do with scatter plot. If you open the attached session file then the colour of the points is not correct. If one then: goes to scatter plots attributes disables the min/max values for the color range apply button enables the min/max values for the color range again- apply button => colours are correct => but min/max values are still 0 Added ESB 4/4/2008: From additional e-mails: Addition: If the plot is in a state where it shows the correct colour with a black background and then tries to swap the background/foreground colours => all points are black (with white background) and I found no way so far to change that.... Ok - a further addition: if I change the sphape into spheres instead of points, change to white background, start the keyframe animation then the colours come back after a few frames and I can even switch now between different background colours and the colours of the points are correct. So there is some wired stuff going on here... but I hope this probably helps to hunt down the bug...

Comments:

should report bad CL options and exit

cqid: VisIt00004378cqsubmitter: Mark Millercqsubmitdate: 01/27/04 I have inadvertently given visit bad commandline arguments on many occasions. However, it neither reports this to me nor fails to start because of them. Maybe I want to collect some debug logs and pass 'debg 5'. Only after I have run visit do I realize I've spelled it wrong. Visit should check all command-line arguments and fail to start of it doesn't recognize any. MCM 25Jan06 Scoring RationaleI rated seriousness as "crash/wrong results" because prior to correcting a specific issue with 'timeout' CL option to engine, the viewer could indeed crash as a result of a missing arg. I haven't tested possibility of this happening for other CL options.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 12
Status: Rejected
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: should report bad CL options and exit
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:09 pm
Updated: 07/06/2010 09:18 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00004378cqsubmitter: Mark Millercqsubmitdate: 01/27/04 I have inadvertently given visit bad commandline arguments on many occasions. However, it neither reports this to me nor fails to start because of them. Maybe I want to collect some debug logs and pass 'debg 5'. Only after I have run visit do I realize I've spelled it wrong. Visit should check all command-line arguments and fail to start of it doesn't recognize any. MCM 25Jan06 Scoring RationaleI rated seriousness as "crash/wrong results" because prior to correcting a specific issue with 'timeout' CL option to engine, the viewer could indeed crash as a result of a missing arg. I haven't tested possibility of this happening for other CL options.

Comments:

should report bad CL options and exit

cqid: VisIt00004378cqsubmitter: Mark Millercqsubmitdate: 01/27/04 I have inadvertently given visit bad commandline arguments on many occasions. However, it neither reports this to me nor fails to start because of them. Maybe I want to collect some debug logs and pass 'debg 5'. Only after I have run visit do I realize I've spelled it wrong. Visit should check all command-line arguments and fail to start of it doesn't recognize any. MCM 25Jan06 Scoring RationaleI rated seriousness as "crash/wrong results" because prior to correcting a specific issue with 'timeout' CL option to engine, the viewer could indeed crash as a result of a missing arg. I haven't tested possibility of this happening for other CL options.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 12
Status: Rejected
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: should report bad CL options and exit
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:09 pm
Updated: 07/06/2010 09:18 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00004378cqsubmitter: Mark Millercqsubmitdate: 01/27/04 I have inadvertently given visit bad commandline arguments on many occasions. However, it neither reports this to me nor fails to start because of them. Maybe I want to collect some debug logs and pass 'debg 5'. Only after I have run visit do I realize I've spelled it wrong. Visit should check all command-line arguments and fail to start of it doesn't recognize any. MCM 25Jan06 Scoring RationaleI rated seriousness as "crash/wrong results" because prior to correcting a specific issue with 'timeout' CL option to engine, the viewer could indeed crash as a result of a missing arg. I haven't tested possibility of this happening for other CL options.

Comments:

Incorrect SIL behavior with time varying SILs.

cqid: VisIt00008464cqsubmitter: Hank Childscqsubmitdate: 01/31/08 This ticket is a big deal for Gunther and I. But I don't have the guts to make the change without consulting the experts. It appears to be a problem with 1.7.1 and with 1.9.0b. Here is a reproducer with the current version of the code. (We are making some changes that exacerbate this problem.) 1) Open /trunk/data/Chombo_plot_data/plot00000.2d.hdf52) Make a PC plot of U_vel3) Bring up the subset window and turn off some levels4) Draw5) Delete the plot6) Make a new PC plot of U_vel7) Bring up the Subset window. All of the levels are on. This is not correct. It should be the same as the SIL restriction from the first plot. However, if you reverse steps 3 and 4, when you look at the subset window in step 7, some of the levels will be off (correctly). Here's what I think is going wrong:In step 4, the call to ViewerPlotList::UpdatePlots() enacts a call to clear the default SIL restrictions. It only clears the default SIL restrictions for time varying data. The default SIL restrictions live as a data member named "SILRestrictions" in the ViewerPlotList. When you reverse steps 3 and 4, it means that the Draw causes the clear to happen before you set the SIL restriction. Since you set the SIL restriction afterwards, it will become the new default and then everything will work correctly. I'm happy to make the change here, but I feel a little gunshy, since this code is so central and there is a chance for unforeseen side effects. Also, note that the bug is actually worse than what I'm describing above. If you make a plot, draw, change the levels, apply the SIL change, delete the plot, and make a new plot, then everythings work fine (the new SIL is preserved). But, if you then delete this new plot and another one, it goes back to turning all of the levels on.(You have to do a SetSILRestriction after each DrawPlots to make it work correctly.)

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 29
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Incorrect SIL behavior with time varying SILs.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008464cqsubmitter: Hank Childscqsubmitdate: 01/31/08 This ticket is a big deal for Gunther and I. But I don't have the guts to make the change without consulting the experts. It appears to be a problem with 1.7.1 and with 1.9.0b. Here is a reproducer with the current version of the code. (We are making some changes that exacerbate this problem.) 1) Open /trunk/data/Chombo_plot_data/plot00000.2d.hdf52) Make a PC plot of U_vel3) Bring up the subset window and turn off some levels4) Draw5) Delete the plot6) Make a new PC plot of U_vel7) Bring up the Subset window. All of the levels are on. This is not correct. It should be the same as the SIL restriction from the first plot. However, if you reverse steps 3 and 4, when you look at the subset window in step 7, some of the levels will be off (correctly). Here's what I think is going wrong:In step 4, the call to ViewerPlotList::UpdatePlots() enacts a call to clear the default SIL restrictions. It only clears the default SIL restrictions for time varying data. The default SIL restrictions live as a data member named "SILRestrictions" in the ViewerPlotList. When you reverse steps 3 and 4, it means that the Draw causes the clear to happen before you set the SIL restriction. Since you set the SIL restriction afterwards, it will become the new default and then everything will work correctly. I'm happy to make the change here, but I feel a little gunshy, since this code is so central and there is a chance for unforeseen side effects. Also, note that the bug is actually worse than what I'm describing above. If you make a plot, draw, change the levels, apply the SIL change, delete the plot, and make a new plot, then everythings work fine (the new SIL is preserved). But, if you then delete this new plot and another one, it goes back to turning all of the levels on.(You have to do a SetSILRestriction after each DrawPlots to make it work correctly.)

Comments:

Choose center on pointvar may hang viewer.

cqid: VisIt00007035cqsubmitter: Eric Bruggercqsubmitdate: 02/17/06 Here is the description from Jeremy Meredith. Open noise.silo PC plot of PointVar Click choose center in the toolbar attempt to click in the window, and it says you didnt click on a plot. Click choose center in the toolbar again NOW it complains that it doesnt have everything it needs to pick. (strange why not the first time?)- so it starts executing the plot, turning it yellow, and never finishes. So this one winds up hanging the viewer, spinning at 100% CPU utilization. Again, Im not particularly interested in a fix, but I thought it should be reported.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 17
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Choose center on pointvar may hang viewer.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 2 - Rare
Severity: 5 - Very Serious
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007035cqsubmitter: Eric Bruggercqsubmitdate: 02/17/06 Here is the description from Jeremy Meredith. Open noise.silo PC plot of PointVar Click choose center in the toolbar attempt to click in the window, and it says you didnt click on a plot. Click choose center in the toolbar again NOW it complains that it doesnt have everything it needs to pick. (strange why not the first time?)- so it starts executing the plot, turning it yellow, and never finishes. So this one winds up hanging the viewer, spinning at 100% CPU utilization. Again, Im not particularly interested in a fix, but I thought it should be reported.

Comments:

Bug with protected/public access in attribute groups

cqid: VisIt00007993cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 04/26/07 From Jeremy Meredith: When generating an attribute subject from an XML file, it looks thereare a couple problems with the code generated for fields when usingaccess settings other than "private". I believe you can expose this bymaking an XML file with a single float field, setting its access toeither "protected" or "public", and trying to compile. For "protected", I would still expect the Set/Get methods to getgenerated, because there's no other way for external clients of theclass to set/get their valuyes. (In fact, should protected be thedefault instead of private? I tend to use protected members more oftenthan private in general.) As for "public", I'm not sure how to Select() the field for notificationwithout using Set/Get, but I suppose that's up to the client. (That'sthe downside of public members to begin with, so maybe that's not aconcern.) But whether or not the Set/Get functions are generated, it looks likethe SetFromNode function is still calling the Set method, which leads toa compilation error. (CreateNode does not seem to use the Get method,however.) At the very least, for public members (and maybe protected ifwe decide they shouldn't have Get/Set functions) members, SetFromNodeshouldn't use the Set function.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 21
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Bug with protected/public access in attribute groups
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007993cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 04/26/07 From Jeremy Meredith: When generating an attribute subject from an XML file, it looks thereare a couple problems with the code generated for fields when usingaccess settings other than "private". I believe you can expose this bymaking an XML file with a single float field, setting its access toeither "protected" or "public", and trying to compile. For "protected", I would still expect the Set/Get methods to getgenerated, because there's no other way for external clients of theclass to set/get their valuyes. (In fact, should protected be thedefault instead of private? I tend to use protected members more oftenthan private in general.) As for "public", I'm not sure how to Select() the field for notificationwithout using Set/Get, but I suppose that's up to the client. (That'sthe downside of public members to begin with, so maybe that's not aconcern.) But whether or not the Set/Get functions are generated, it looks likethe SetFromNode function is still calling the Set method, which leads toa compilation error. (CreateNode does not seem to use the Get method,however.) At the very least, for public members (and maybe protected ifwe decide they shouldn't have Get/Set functions) members, SetFromNodeshouldn't use the Set function.

Comments:

cell_constant, point_constant expressions don't take vector constants

cqid: VisIt00008560cqsubmitter: Brad Whitlockcqsubmitdate: 03/20/08 I was investigating how to create a constant vector over a mesh and I came upon the recently added cell_constant and point_constant expressions. These are just what I needed except they don't take constant vector expressions; just scalars. MCM Added 31Mar08We concluded that vector types were NOT the only types that may need to be considered here. We may also need to deal with array, color, tensor, etc.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 48
Status: Rejected
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: cell_constant, point_constant expressions don't take vector constants
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 07/06/2010 09:11 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008560cqsubmitter: Brad Whitlockcqsubmitdate: 03/20/08 I was investigating how to create a constant vector over a mesh and I came upon the recently added cell_constant and point_constant expressions. These are just what I needed except they don't take constant vector expressions; just scalars. MCM Added 31Mar08We concluded that vector types were NOT the only types that may need to be considered here. We may also need to deal with array, color, tensor, etc.

Comments:
It is possible to create necessary expressions by construction from scalar constant expressions. For example, {point_constant(mesh1, 2.732),point_constant(mesh1, 2.732),point_constant(mesh1, 2.732)} will create a constant vector.

Provide an OpenCLI() cli method which launches a new cli instance

rmid: 38rmsubmitter: Cyrus Harrisonrmsubmitdate: 05/14/2010 03:05 pm When using the visitmodule, Bob Corey expected visit.AddArgument("-cli") to pop up a new cli window when visit.Launch() was called. What he actually wants is the ability to launch a new cli instance from the VisIt python module, similar to OpenGUI(). So we should provide an OpenCLI() method to enable this.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 23
Status: Resolved
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Provide an OpenCLI() cli method which launches a new cli instance
Assigned to: Cyrus Harrison
Category: -
Target version: 2.1
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:14 pm
Updated: 07/14/2010 03:01 pm
Likelihood:
Severity:
Found in version: 2.0.0
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
rmid: 38rmsubmitter: Cyrus Harrisonrmsubmitdate: 05/14/2010 03:05 pm When using the visitmodule, Bob Corey expected visit.AddArgument("-cli") to pop up a new cli window when visit.Launch() was called. What he actually wants is the ability to launch a new cli instance from the VisIt python module, similar to OpenGUI(). So we should provide an OpenCLI() method to enable this.

Comments:
We believe this was resolved, Cyrus will check for 2.0.2 What Bob actually wants is the ability to launch a new cli window from the VisIt python module, similar to OpenGUI() - we should provide OpenCLI(). Hi Everyone,I added an 'OpenCLI()' to the cli, which spawns a new cli instance.Sending visitpy/common/visitmodule.CCommitted revision r11882.-Cyrus

MDserver crashes reading ddcMD data on MAC

cqid: VisIt00008641cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 06/09/08 Dave Richards sent data and log files.Opening the file on MAC crashes the MDSever.The log files indicate a SIGBUS. He reports all other platforms work fine. I confirmed VisIt 1.9 on linux can read his data. Data is on OCF /usr/gapps/visit/bug_data/visit_bug_8641.tar.gz

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 31
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: MDserver crashes reading ddcMD data on MAC
Assigned to: Cyrus Harrison
Category: -
Target version: 2.1.2
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 12/10/2010 05:18 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008641cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 06/09/08 Dave Richards sent data and log files.Opening the file on MAC crashes the MDSever.The log files indicate a SIGBUS. He reports all other platforms work fine. I confirmed VisIt 1.9 on linux can read his data. Data is on OCF /usr/gapps/visit/bug_data/visit_bug_8641.tar.gz

Comments:
Assignment from LLNL review meeting. Update from LLNL team meeting. This still occurs on OSX in 2.1.1.Here is the trace:#4 0x0000000102fa506f in object_parse ()(gdb) up#5 0x0000000102fa5248 in object_get ()(gdb) up#6 0x0000000102f9e732 in DDCMDHeader::DDCMDHeader ()I will tackle this after building a debug ver. ~@490 (object.C)The offending code appears to be the deref of tail in the following:This is at the end of a while which tokenizes a header string until vtpr == NULL.It appears that some how on osx, &tail is NULL, but vptr is not. Hi Everyone,Resolved an OSXcrash due to a null pointer derefernce in the ddcMD reader.Added my updates to the release notes for 2.1.2.RC:Sending databases/DDCMD/object.CSending help/en_US/relnotes2.1.2.htmlTransmitting file data ..Committed revision r13240.Trunk:Sending databases/DDCMD/object.CSending help/en_US/relnotes2.1.2.htmlTransmitting file data ..Committed revision r13242.Cyrus

Would like the VisIt help to be searchable

cqid: VisIt00009032cqsubmitter: Eric Bruggercqsubmitdate: 03/22/10 Matt O'Brien would like the help in VisIt to be searchable. Matt suggested that this could be accomplished by adding an option thebrought up a PDF version of the manual, which could then be searchedusing the PDF viewer's search capabilities. Matt's e-mail: What if one of the "help" options was to bring up a pdf of the entire visit manual. Then you could use the search feature of the pdf reader to find what you're looking for. -Matt

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 51
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Would like the VisIt help to be searchable
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00009032cqsubmitter: Eric Bruggercqsubmitdate: 03/22/10 Matt O'Brien would like the help in VisIt to be searchable. Matt suggested that this could be accomplished by adding an option thebrought up a PDF version of the manual, which could then be searchedusing the PDF viewer's search capabilities. Matt's e-mail: What if one of the "help" options was to bring up a pdf of the entire visit manual. Then you could use the search feature of the pdf reader to find what you're looking for. -Matt

Comments:

Overlayed curve view can get out of sink with 2d plot view.

cqid: VisIt00008835cqsubmitter: Cyrus Harrisoncqsubmitdate: 12/08/08 1) Open rect2d.silo2) Make a Boundary Plot of "mat", turn on only mats 16,183) Set the Save Window options to output an ultra file and save4) Close VisIt 5) Restart VisIt and open and plot the new curve file.6) Open rect2d.silo and create the Boundary plot from step 2. Notice the curves do not match - this appears to be b/c the curve view is out of sink with the 2d view. If you delete both plots, and draw the boundary plot before the curve, the views will match.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 45
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Overlayed curve view can get out of sink with 2d plot view.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008835cqsubmitter: Cyrus Harrisoncqsubmitdate: 12/08/08 1) Open rect2d.silo2) Make a Boundary Plot of "mat", turn on only mats 16,183) Set the Save Window options to output an ultra file and save4) Close VisIt 5) Restart VisIt and open and plot the new curve file.6) Open rect2d.silo and create the Boundary plot from step 2. Notice the curves do not match - this appears to be b/c the curve view is out of sink with the 2d view. If you delete both plots, and draw the boundary plot before the curve, the views will match.

Comments:

Move test dashboard and visit.llnl.gov site to gh-pages site

Currently, we host VisIt's test results "dashboard" via https from /project at NERSC. Because our subversion repo wasn't hosted via http their as well (or was but that functionality was removed), we took to copying a ton of test result (e.g. baselines) content from our repo to the "dashboard" (as opposed to simply linking to it) for each test run.

On NERSC's /project, that was hugely abusive (due to file block size quantification), each test run taking ~1.5Gb, whereas the same html dir-tree on Linux is ~100Mb. When we include savings due to even modest revision of the way we gen dashboard results, I believe it is possible to cut per-test storage cost < ~10Mb per run (way less when all/most tests pass).

With GitHub limit of 1000Mb on repo and gh-pages served site, that would allow us to host 100+ past results without exceeding GitHub limits. At 3-5 modes per night, thats >20-33 past results which I think is perfectly sufficient for our needs.

Beyond the fact that GitHub pages site is an available resource and we can make it work, I see a number of advantages in moving this aspect of our project to GitHub...

  • We are no longer dependent on NERSC /project or NERSC servers to host test dashboard
  • GitHub is a large company with a lot of experience hosting a lot of projects. It doesn't break down.
  • We don't need special access (ssh proxy with 1 week limits) to publish results
  • More core developers have more natural/immediate access to affect changes or respond to things when they break
  • It makes VisIt development more one-stop-shopping @ GitHub instead of a frankenstien of resources (which I see value in getting away from)
  • We have a lot of tools for controlling look and feel of the dashboard site
  • We can support test results from multiple user's runs who wouldn't ordinarily have an account on NERSC to scp results to.

I think several similar arguments apply to content on visit.llnl.gov...we should move it to a gh-pages site and have visit.llnl.gov simply re-direct to that new site. Its easier to modify, update, change look and feel, etc.

For an example of what I am talking about, see here...

https://visit-dav.github.io/dashboard/

In particular, follow the "Test" tab to get to very simple brute-force copy of a recent test result. None of the other links there work because I was just trying to stand up a simple demo of what is possible and, in particular, show that emulating the current look-and-feel is totally doable, but that we can easily edit the content ourselves, as I did to add the "Test" tab.

Revolve Operator ignores vectors

cqid: VisIt00008194cqsubmitter: Ellen Tarwatercqsubmitdate: 08/15/07 Janet Jacobsen from LBL reports that the Revolve Operator is not applying the transform to vectors.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 38
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Revolve Operator ignores vectors
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 2 - Rare
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008194cqsubmitter: Ellen Tarwatercqsubmitdate: 08/15/07 Janet Jacobsen from LBL reports that the Revolve Operator is not applying the transform to vectors.

Comments:

We're too heavy handed at invalidating plots

cqid: VisIt00007616cqsubmitter: Mark Millercqsubmitdate: 12/05/06 A user spent a lot of time (several hours) getting a series of queries over time into a VisIt window. He had several curves there generated throughout the morning. Then, he accidentally tried to add a PC plot of a mesh variable to the window with the curves in it. That operation threw an exception (plot dimensions don't match or something like that) and then promptly invalidated all his time curves. They were gone for good. First, we probably should not be invalidating existing plots because a new plot was not valid. Second, what can we do to protect users against this loss of information, particular long operations such as queries over time? This user has since taken to exporting dbs after he generates his time curves. MCM Added 08Jan07The narrative above was taken verbatim from a conversation with the user. While I have been UNABLE to reproduce this specific behavior, I have been ABLE to reproduce a behavior just as bad by instead of "...accidentally adding a pc plot..." accidentally applying a slice operator. Open wave*.silo. Put up a pc plot of pressure.Bring up pick attributes.Select "create time curve on next pick," hit apply.Do a NODE pick. The curve is generated.Now, add a slice operator to window 2.The time curve plot is invalidated and there isno way to recover it.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 20
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: We're too heavy handed at invalidating plots
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007616cqsubmitter: Mark Millercqsubmitdate: 12/05/06 A user spent a lot of time (several hours) getting a series of queries over time into a VisIt window. He had several curves there generated throughout the morning. Then, he accidentally tried to add a PC plot of a mesh variable to the window with the curves in it. That operation threw an exception (plot dimensions don't match or something like that) and then promptly invalidated all his time curves. They were gone for good. First, we probably should not be invalidating existing plots because a new plot was not valid. Second, what can we do to protect users against this loss of information, particular long operations such as queries over time? This user has since taken to exporting dbs after he generates his time curves. MCM Added 08Jan07The narrative above was taken verbatim from a conversation with the user. While I have been UNABLE to reproduce this specific behavior, I have been ABLE to reproduce a behavior just as bad by instead of "...accidentally adding a pc plot..." accidentally applying a slice operator. Open wave*.silo. Put up a pc plot of pressure.Bring up pick attributes.Select "create time curve on next pick," hit apply.Do a NODE pick. The curve is generated.Now, add a slice operator to window 2.The time curve plot is invalidated and there isno way to recover it.

Comments:

Label format in legend does not apply to Contour labels, only min/max

cqid: VisIt00008978cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 09/30/09 Changing the 'number format' for a contour plot's legend hasno effect on the tick-mark labels, only on min/max. I noticed this while working on some changes to the legends.I don't know if users would even want to change this ... butI thought I'd document the problem. Current implementation details: Our vtk class for legends has the ability for tick mark labelsfor 'levels' type legends to be supplied as strings or doubles. Currently, no plot sends the values as double. I would expectContour plot to be using the double-path, since its labels are the isovalues used in generating the plot. However, the isovalues are generated by avtContourFilter, andthose double values are converted to strings using a hard-codednumber format. The strings are then sent as 'labels' attachedto the vtkDataSets in the pipeline. Contour plot retrievesthose string labels and sends them to the levels legend. When the legend's number format is changed, the tick marklabels are not affected, obviously, because they are strings,not doubles.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 25
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Label format in legend does not apply to Contour labels, only min/max
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:14 pm
Updated:
Likelihood: 2 - Rare
Severity: 1 - Not Serious
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008978cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 09/30/09 Changing the 'number format' for a contour plot's legend hasno effect on the tick-mark labels, only on min/max. I noticed this while working on some changes to the legends.I don't know if users would even want to change this ... butI thought I'd document the problem. Current implementation details: Our vtk class for legends has the ability for tick mark labelsfor 'levels' type legends to be supplied as strings or doubles. Currently, no plot sends the values as double. I would expectContour plot to be using the double-path, since its labels are the isovalues used in generating the plot. However, the isovalues are generated by avtContourFilter, andthose double values are converted to strings using a hard-codednumber format. The strings are then sent as 'labels' attachedto the vtkDataSets in the pipeline. Contour plot retrievesthose string labels and sends them to the levels legend. When the legend's number format is changed, the tick marklabels are not affected, obviously, because they are strings,not doubles.

Comments:

movie wizard generated bogus params file from iconified window

cqid: VisIt00008732cqsubmitter: Mark Millercqsubmitdate: 09/17/08 A user tried to use the movie wizard to make a movie. As he switched between desktops, VisIt's window became iconified. So, he started the movie wizard with VisIt's window in an iconified state and quickly marched through all the dialogs not paying any attention to the window size that it had chosen. The result was 100 frames of pnm images at 300x300 resolution (not the iconified size of the window but not the DE-icondified size of the window either) and a bogus params file that caused mpeg2encode to die; horizontal and vertical sizes were 0 and bitrate was zero.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 32
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: movie wizard generated bogus params file from iconified window
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 2 - Rare
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008732cqsubmitter: Mark Millercqsubmitdate: 09/17/08 A user tried to use the movie wizard to make a movie. As he switched between desktops, VisIt's window became iconified. So, he started the movie wizard with VisIt's window in an iconified state and quickly marched through all the dialogs not paying any attention to the window size that it had chosen. The result was 100 frames of pnm images at 300x300 resolution (not the iconified size of the window but not the DE-icondified size of the window either) and a bogus params file that caused mpeg2encode to die; horizontal and vertical sizes were 0 and bitrate was zero.

Comments:

need intrinsic/extrinsic flag for re-centering operations

cqid: VisIt00008584cqsubmitter: Mark Millercqsubmitdate: 04/15/08 I listed this as a bug but one could argue that it is really an enhancement request. The user reported that after recenter a mass quantity from its native zonecentered state to a nodecentered state, mass was created. As we spoke, it made perfect sense to me given what recentering in VisIt is doing. When we recenter in VisIt from zones to nodes, we... a) visit each node b) find all zones that share the node c) add up the zonal values for those zones d) divide (average) by the number of zones However, the user explained that for the mass quantity he wasdealing with, the right algorithm is... a) visit each zone b) divide the zonal value by the number of nodes the zone has c) accumulate the value to each of the zone's nodes This is fundamentally the difference between an intrinsic and extrinsic quantity. An intrinsic quantity is one that DOES NOT change as you cut a zone into smaller pieces. Temperature is an example. If you cut a zone of temperature T0 into two pieces, each piece will have temperature T0. However, if you cut a zone of mass M1 into pieces, each piece will have a mass different from M1 (usually related to volume differences assuming a constant density) VisIt needs to know the 'intrinsic'/'extrinsic' nature of its variables. That is a new flag on all avtXXXMetaData objects which can have the values; Extrinsic, Intrinsic, Unspecified. In the case that a variable's intrinsicness is Unspecified, the user needs the ability to specify which recentering algorithm above to use. So, recenter in PC plot and recenter expression need an option for this. A separate ticket is for Silo to include extrnisic/intrinsic options in its variables.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 24
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: need intrinsice/extrinsic flag for re-centering operations
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:14 pm
Updated:
Likelihood: 4 - Common
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008584cqsubmitter: Mark Millercqsubmitdate: 04/15/08 I listed this as a bug but one could argue that it is really an enhancement request. The user reported that after recenter a mass quantity from its native zonecentered state to a nodecentered state, mass was created. As we spoke, it made perfect sense to me given what recentering in VisIt is doing. When we recenter in VisIt from zones to nodes, we... a) visit each node b) find all zones that share the node c) add up the zonal values for those zones d) divide (average) by the number of zones However, the user explained that for the mass quantity he wasdealing with, the right algorithm is... a) visit each zone b) divide the zonal value by the number of nodes the zone has c) accumulate the value to each of the zone's nodes This is fundamentally the difference between an intrinsic and extrinsic quantity. An intrinsic quantity is one that DOES NOT change as you cut a zone into smaller pieces. Temperature is an example. If you cut a zone of temperature T0 into two pieces, each piece will have temperature T0. However, if you cut a zone of mass M1 into pieces, each piece will have a mass different from M1 (usually related to volume differences assuming a constant density) VisIt needs to know the 'intrinsic'/'extrinsic' nature of its variables. That is a new flag on all avtXXXMetaData objects which can have the values; Extrinsic, Intrinsic, Unspecified. In the case that a variable's intrinsicness is Unspecified, the user needs the ability to specify which recentering algorithm above to use. So, recenter in PC plot and recenter expression need an option for this. A separate ticket is for Silo to include extrnisic/intrinsic options in its variables.

Comments:

Problem looking at subset of domains when material selected.

cqid: VisIt00005235cqsubmitter: Hank Childscqsubmitdate: 07/22/04 Open up balls.exodus Make a subset plot of File.Draw. Fine and good. Now bring up the SIL window and remove Element Blocks 1,2and 3. Click apply.You get the error message:Subset (BadIndexException): Tried to access an invalid index -1 (Maximum = 3).

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 15
Status: Expired
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Problem looking at subset of domains when material selected.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated: 11/15/2018 05:47 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00005235cqsubmitter: Hank Childscqsubmitdate: 07/22/04 Open up balls.exodus Make a subset plot of File.Draw. Fine and good. Now bring up the SIL window and remove Element Blocks 1,2and 3. Click apply.You get the error message:Subset (BadIndexException): Tried to access an invalid index -1 (Maximum = 3).

Comments:
Doesn't seem to be a problem anymore (as of 2.13.3).

missing mesh lines from arb. polyhedral mesh

cqid: VisIt00009013cqsubmitter: Mark Millercqsubmitdate: 01/27/10 VisIt contains logic to remove what it thinks are 'internal' edges from a mesh plot when it renders them. It uses avtOriginalZoneNumbers to drive this logic. I think the logic is... ...given an edge, if all the zones that share that edge have the same 'avtOriginalZoneNumber', the edge is removed. However, this fails on edges that are in fact external to the whole plot as it removes them when it should not. So, if an edge is external to the whole plot, keep it regardless, otherwise, remove as per current algorithm. You can see this behavior when plotting arb. polyhedral data from silo.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 27
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: missing mesh lines from arb. polyhedral mesh
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 2 - Minor Irritation
Found in version: 1.12.2
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00009013cqsubmitter: Mark Millercqsubmitdate: 01/27/10 VisIt contains logic to remove what it thinks are 'internal' edges from a mesh plot when it renders them. It uses avtOriginalZoneNumbers to drive this logic. I think the logic is... ...given an edge, if all the zones that share that edge have the same 'avtOriginalZoneNumber', the edge is removed. However, this fails on edges that are in fact external to the whole plot as it removes them when it should not. So, if an edge is external to the whole plot, keep it regardless, otherwise, remove as per current algorithm. You can see this behavior when plotting arb. polyhedral data from silo.

Comments:

would be nice if visit could accept pre-computed MIR from DB

cqid: VisIt00003876cqsubmitter: Mark Millercqsubmitdate: 10/09/03 The SAMRAI folks are beginning work on their own MIR algorithms whichthey will be using within their code. They'll need to debug it andwould like to visualize the MIR as they computed it, not as VisItwould. There are multiple approache here. Some involve exchange of code thatcomputes the MIR. Another approach is to allow for the pre-computedMIR to be stored to the database. This might be possible withoutmodifying Silo. Here is the basic idea. The original mesh is simply a zoo of elements (for QuadMesh's its azoo of size 1). The precomputed MIR has the effect of NOT changingany elements that are clean and introducing a tiny zoo of elements onany elements that are mixing. In theory, a dataproducer could make aUCD mesh (or several of them) consiting of the union of all the newelements introduced by MIR. It would be a funny mesh in that it wouldbe approx 1 originalmeshzone thick and wind around the 3D volumefollowing the MIR boundaries. But it would nonetheless be an objectSilo currently supports. The only additional bit of information thatmight be useful is to define a UCDVar on the MIR mesh that identifiedthe originalmeshzone id from which the newly introduced zones comefrom. Given this information in the file, VisIt would then offer an optionof either computing its own MIR or using the one thats there.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 10
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: would be nice if visit could accept pre-computed MIR from DB
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 05:35 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 5 - Very High
Expected Use: 4 - Common
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00003876cqsubmitter: Mark Millercqsubmitdate: 10/09/03 The SAMRAI folks are beginning work on their own MIR algorithms whichthey will be using within their code. They'll need to debug it andwould like to visualize the MIR as they computed it, not as VisItwould. There are multiple approache here. Some involve exchange of code thatcomputes the MIR. Another approach is to allow for the pre-computedMIR to be stored to the database. This might be possible withoutmodifying Silo. Here is the basic idea. The original mesh is simply a zoo of elements (for QuadMesh's its azoo of size 1). The precomputed MIR has the effect of NOT changingany elements that are clean and introducing a tiny zoo of elements onany elements that are mixing. In theory, a dataproducer could make aUCD mesh (or several of them) consiting of the union of all the newelements introduced by MIR. It would be a funny mesh in that it wouldbe approx 1 originalmeshzone thick and wind around the 3D volumefollowing the MIR boundaries. But it would nonetheless be an objectSilo currently supports. The only additional bit of information thatmight be useful is to define a UCDVar on the MIR mesh that identifiedthe originalmeshzone id from which the newly introduced zones comefrom. Given this information in the file, VisIt would then offer an optionof either computing its own MIR or using the one thats there.

Comments:

help still points users to obsolete -default_format command line flag

cqid: VisIt00008937cqsubmitter: Cyrus Harrisoncqsubmitdate: 06/11/09 Under: "Working with databases" > "Supported File Types" > "File Extensions" Help still lists 'default_format' as the method to force a database type via the command line. It should be updated with 'force_format' and 'assume_foramt'

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 43
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: help still points users to obsolete -default_format command line flag
Assigned to: Eric Brugger
Category: -
Target version: 2.1
Author: Cyrus Harrison
Start:
Due date:
% Done: 100%
Estimated time: 2.00 hours
Created: 06/21/2010 07:15 pm
Updated: 08/24/2010 01:07 pm
Likelihood: 2 - Rare
Severity: 2 - Minor Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008937cqsubmitter: Cyrus Harrisoncqsubmitdate: 06/11/09 Under: "Working with databases" > "Supported File Types" > "File Extensions" Help still lists 'default_format' as the method to force a database type via the command line. It should be updated with 'force_format' and 'assume_foramt'

Comments:
Cyrus Harrison wrote:cq-id: VisIt00008937 cq-submitter: Cyrus Harrison cqsubmitdate: 06/11/09Under:"Working with databases" > "Supported File Types" > "File Extensions"Help still lists 'default_format' as the method to force a database type via the command line. It should be updated with 'force_format' and 'assume_format' I updated the help text as specified in the description.The help text used to be autogenerated from the users manual but this is no longer the case, so I modified the help text directly. If we ever go back to autogenerating the text this could get lost.I modified help/en_US/help0013.html.

add version check to build_visit

cqid: VisIt00008800cqsubmitter: Mark Millercqsubmitdate: 11/05/08 The build_visit script has logic that is somewhat specific to the structure, contents of a visit source code tree. So, we ought to start adding version checking logic to it to abort and print a nice error message whenever it is being used to build a version of VisIt it was not designed for. This would prevent a lot of messages to the help line such as those recently related to hdf5.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 44
Status: Rejected
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: add version check to build_visit
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 07/06/2010 09:06 pm
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 4 - High
Expected Use: 2 - Rare
OS: All
Support Group: Any
Description:
cqid: VisIt00008800cqsubmitter: Mark Millercqsubmitdate: 11/05/08 The build_visit script has logic that is somewhat specific to the structure, contents of a visit source code tree. So, we ought to start adding version checking logic to it to abort and print a nice error message whenever it is being used to build a version of VisIt it was not designed for. This would prevent a lot of messages to the help line such as those recently related to hdf5.

Comments:

Slice/Elevate error w/ issue parallel engine

cqid: VisIt00009021cqsubmitter: Cyrus Harrisoncqsubmitdate: 02/11/10 Gary Kerbel called and reported a problem using slice + elevate on alastor in parallel. Data @ /g/g24/cyrush/visit/ticket009021 on OCF. Add PC Plot of JzSlice on Z AxisElevate rel to xy limits. When using 16 processors on alastor, the correct plot is produced.When using 32 a large hole appears in the plot, it looks like it is an extents used to elevate are incorrect for a subset of the problem.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 26
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Slice/Elevate error w/ issue parallel engine
Assigned to: Cyrus Harrison
Category: -
Target version: 2.2
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:14 pm
Updated: 01/05/2011 02:47 pm
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00009021cqsubmitter: Cyrus Harrisoncqsubmitdate: 02/11/10 Gary Kerbel called and reported a problem using slice + elevate on alastor in parallel. Data @ /g/g24/cyrush/visit/ticket009021 on OCF. Add PC Plot of JzSlice on Z AxisElevate rel to xy limits. When using 16 processors on alastor, the correct plot is produced.When using 32 a large hole appears in the plot, it looks like it is an extents used to elevate are incorrect for a subset of the problem.

Comments:
Assignment from LLNL release meeting Hi Everyone,I resolved an issue with the Elevate operator in parallel. The spatial extents were not unified across processors, this caused different processors to use different elevation limits yielding a discontinuous result surface. This check in resolves issue #26 (https://visitbugs.ornl.gov/issues/26).The surface filter was using avtDatasetExaminer::GetSpatialExtents to obtain the spatial extents. This function only returns the spatial extents on the current processor an additional UnifyMinMax call was missing.Note:Searching for other instances where avtDatasetExaminer::GetSpatialExtents is used, there are a handful of instances that do unify the spatial extents and a handful that do not. This lead me to wonder if some of the other instances that do not unify the extents are actually bugs...Sending avt/Filters/avtSurfaceFilter.CTransmitting file data .Committed revision r13434.Cyrus

Limiting range of query over time is broken

cqid: VisIt00008985cqsubmitter: Eric Bruggercqsubmitdate: 10/09/09 Hank Shay was trying to limit the extent of a query over time and ran into several problems.He was looking at silo files and the time slider displayed cycle numbers so it had not readthe times from all the files. So here are his problems. 1) He tried to limit it by time and specified a time less than between 0 and 1 and theGUI just set it to 0 after he hit Apply. I assume the GUI is code so as to only takeintegers. It should take them for times. 2) He tried to limit it by cycle and set it to a reasonable cycle and then it said that itwas out of range. When he did the query it did the entire range. I also played with query over time with wave and set the cycle range to be 10 to 50, whichworked, but the cycles displayed on the x axis went from 100 to 500. I don't know why thiswas off by a factor of 10.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 42
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Limiting range of query over time is broken
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008985cqsubmitter: Eric Bruggercqsubmitdate: 10/09/09 Hank Shay was trying to limit the extent of a query over time and ran into several problems.He was looking at silo files and the time slider displayed cycle numbers so it had not readthe times from all the files. So here are his problems. 1) He tried to limit it by time and specified a time less than between 0 and 1 and theGUI just set it to 0 after he hit Apply. I assume the GUI is code so as to only takeintegers. It should take them for times. 2) He tried to limit it by cycle and set it to a reasonable cycle and then it said that itwas out of range. When he did the query it did the entire range. I also played with query over time with wave and set the cycle range to be 10 to 50, whichworked, but the cycles displayed on the x axis went from 100 to 500. I don't know why thiswas off by a factor of 10.

Comments:

Synchronization issue between GUI and CLI with opened databases.

cqid: VisIt00007022cqsubmitter: Hank Childscqsubmitdate: 02/14/06 If I start up the GUI, and then launch a CLI, and then invokea script that does:OpenDatabase("/usr/gapps/visit/data/curv2d.silo")AddPlot("Pseudocolor", "d")DrawPlots() Then the GUI's "Open" button says "ReOpen". But ReOpen doesnothing. I would expect that it says Open and doesn't understandthat curv2d is the currently open file. Or I would expect forReOpen to reopen curv2d. Ideally, curv2d.silo would have been added to the selected fileslist, but that may be a tall order. Added, HRC, 3/3/06:Kevin Roe called in a more serious form of this ticket.He would like for the file to show up in the selectedfiles list.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 16
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Synchronization issue between GUI and CLI with opened databases.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 4 - Common
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007022cqsubmitter: Hank Childscqsubmitdate: 02/14/06 If I start up the GUI, and then launch a CLI, and then invokea script that does:OpenDatabase("/usr/gapps/visit/data/curv2d.silo")AddPlot("Pseudocolor", "d")DrawPlots() Then the GUI's "Open" button says "ReOpen". But ReOpen doesnothing. I would expect that it says Open and doesn't understandthat curv2d is the currently open file. Or I would expect forReOpen to reopen curv2d. Ideally, curv2d.silo would have been added to the selected fileslist, but that may be a tall order. Added, HRC, 3/3/06:Kevin Roe called in a more serious form of this ticket.He would like for the file to show up in the selectedfiles list.

Comments:

Movie script does not handle case where a viewport does not have sequences.

cqid: VisIt00007844cqsubmitter: Brad Whitlockcqsubmitdate: 03/01/07 Al Nichols was using the new movie template code in VisIt and he created a 2x2 viewport layout but only mapped sequences to viewports 0,1,2 and not to 3. The movie script chugged through generating images for the first 3 viewports and died on the 4th since it had no sequences. It probably died in the compositing phase of the script. The movie script should be fixed so it can handle viewports with no sequences. Al's work-around was to create a custom viewport mapping with 3 viewports

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 18
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Movie script does not handle case where a viewport does not have sequences.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 2 - Rare
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007844cqsubmitter: Brad Whitlockcqsubmitdate: 03/01/07 Al Nichols was using the new movie template code in VisIt and he created a 2x2 viewport layout but only mapped sequences to viewports 0,1,2 and not to 3. The movie script chugged through generating images for the first 3 viewports and died on the 4th since it had no sequences. It probably died in the compositing phase of the script. The movie script should be fixed so it can handle viewports with no sequences. Al's work-around was to create a custom viewport mapping with 3 viewports

Comments:

Expressions involving mixed-scalars do not return results that are also mixed.

cqid: VisIt00007394cqsubmitter: Brad Whitlockcqsubmitdate: 07/26/06 Added, HRC, 3/18/07:Here is a reproducer.Open up ~whitlocb/data/zzzz00000.silo. Make an expression called "ratio" that is defined as "den/p". Both den and p are mixed. Turn on "Force interface reconstruction". You can see that ratio is also getting defined as mixed.Now pick on ratio. It returns a single value for the zone.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 14
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Expressions involving mixed-scalars do not return results that are also mixed.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 2 - Rare
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007394cqsubmitter: Brad Whitlockcqsubmitdate: 07/26/06 Added, HRC, 3/18/07:Here is a reproducer.Open up ~whitlocb/data/zzzz00000.silo. Make an expression called "ratio" that is defined as "den/p". Both den and p are mixed. Turn on "Force interface reconstruction". You can see that ratio is also getting defined as mixed.Now pick on ratio. It returns a single value for the zone.

Comments:

Parallel engine doesn't relaunch after crash/timeout when using the cli

rmid: 50rmsubmitter: Cyrus Harrisonrmsubmitdate: 06/14/2010 04:40 pm Rich Cook reports that when using the cli after an engine crashes it appears VisIt does not try to relaunch the engine using the previous engine params. This used to be the case in VisIt 1.x.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 28
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Parallel engine doesn't relaunch after crash/timeout when using the cli
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 07/13/2010 05:09 pm
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
rmid: 50rmsubmitter: Cyrus Harrisonrmsubmitdate: 06/14/2010 04:40 pm Rich Cook reports that when using the cli after an engine crashes it appears VisIt does not try to relaunch the engine using the previous engine params. This used to be the case in VisIt 1.x.

Comments:
Turns out in this case, we were caching an empty machine profile, but when we went to stuff the user's args into that cached profile, the args need to go into a launch profile. But an empty machine profile has NO launch profiles. I changed it to create an empty launch profile (and make it active) in this case, so we have a place to stuff those arguments.

Hard to see error message when cannot open visit.py during Macro recording

cqid: VisIt00008001cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 04/30/07 If the cli cannot open 'visit.py' log file, Macro recordingfails. A message is printed in the cli window, but is a bit hard to see, due to the fact it gets printed before the 'Added new client' message (see below), plus, attention is on the Macro window, not the cli. Can we also add this message to the gui when doing Macrorecording, otherwise recording appears to fail 'silently'. Could not open visit.py log file.VisIt: Message Added a new client to the viewer.Python 2.1.2 (#1, Nov 3 2005, 14:49:32) [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2Type "copyright", "credits" or "license" for more information.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 35
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Hard to see error message when cannot open visit.py during Macro recording
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008001cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 04/30/07 If the cli cannot open 'visit.py' log file, Macro recordingfails. A message is printed in the cli window, but is a bit hard to see, due to the fact it gets printed before the 'Added new client' message (see below), plus, attention is on the Macro window, not the cli. Can we also add this message to the gui when doing Macrorecording, otherwise recording appears to fail 'silently'. Could not open visit.py log file.VisIt: Message Added a new client to the viewer.Python 2.1.2 (#1, Nov 3 2005, 14:49:32) [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2Type "copyright", "credits" or "license" for more information.

Comments:

Remote host name does not replace 'local host' in File open window after connecting

rmid: 18rmsubmitter: Anonymousrmsubmitdate: 04/19/2010 02:56 pm I used 'File open' to connect to yana. While connecting, "LLNL yana" was in theHost field. After connection, it reverted to 'localhost'. That's a bit confusing. My local machine is linux 2.4.31, running an install of 'linux-rhel3' (compiled on hoth).

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 37
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Remote host name does not replace 'local host' in File open window after connecting
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 3 - Occasional
Severity: 2 - Minor Irritation
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
rmid: 18rmsubmitter: Anonymousrmsubmitdate: 04/19/2010 02:56 pm I used 'File open' to connect to yana. While connecting, "LLNL yana" was in theHost field. After connection, it reverted to 'localhost'. That's a bit confusing. My local machine is linux 2.4.31, running an install of 'linux-rhel3' (compiled on hoth).

Comments:

would be nice if visit could accept pre-computed MIR from DB

cqid: VisIt00003876cqsubmitter: Mark Millercqsubmitdate: 10/09/03 The SAMRAI folks are beginning work on their own MIR algorithms whichthey will be using within their code. They'll need to debug it andwould like to visualize the MIR as they computed it, not as VisItwould. There are multiple approache here. Some involve exchange of code thatcomputes the MIR. Another approach is to allow for the pre-computedMIR to be stored to the database. This might be possible withoutmodifying Silo. Here is the basic idea. The original mesh is simply a zoo of elements (for QuadMesh's its azoo of size 1). The precomputed MIR has the effect of NOT changingany elements that are clean and introducing a tiny zoo of elements onany elements that are mixing. In theory, a dataproducer could make aUCD mesh (or several of them) consiting of the union of all the newelements introduced by MIR. It would be a funny mesh in that it wouldbe approx 1 originalmeshzone thick and wind around the 3D volumefollowing the MIR boundaries. But it would nonetheless be an objectSilo currently supports. The only additional bit of information thatmight be useful is to define a UCDVar on the MIR mesh that identifiedthe originalmeshzone id from which the newly introduced zones comefrom. Given this information in the file, VisIt would then offer an optionof either computing its own MIR or using the one thats there.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 10
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: would be nice if visit could accept pre-computed MIR from DB
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 05:35 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 5 - Very High
Expected Use: 4 - Common
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00003876cqsubmitter: Mark Millercqsubmitdate: 10/09/03 The SAMRAI folks are beginning work on their own MIR algorithms whichthey will be using within their code. They'll need to debug it andwould like to visualize the MIR as they computed it, not as VisItwould. There are multiple approache here. Some involve exchange of code thatcomputes the MIR. Another approach is to allow for the pre-computedMIR to be stored to the database. This might be possible withoutmodifying Silo. Here is the basic idea. The original mesh is simply a zoo of elements (for QuadMesh's its azoo of size 1). The precomputed MIR has the effect of NOT changingany elements that are clean and introducing a tiny zoo of elements onany elements that are mixing. In theory, a dataproducer could make aUCD mesh (or several of them) consiting of the union of all the newelements introduced by MIR. It would be a funny mesh in that it wouldbe approx 1 originalmeshzone thick and wind around the 3D volumefollowing the MIR boundaries. But it would nonetheless be an objectSilo currently supports. The only additional bit of information thatmight be useful is to define a UCDVar on the MIR mesh that identifiedthe originalmeshzone id from which the newly introduced zones comefrom. Given this information in the file, VisIt would then offer an optionof either computing its own MIR or using the one thats there.

Comments:

Add some path to tease out negative volume tets.

cqid: VisIt00008918cqsubmitter: Cyrus Harrisoncqsubmitdate: 04/10/09 Hank Shay has some data where the simulation says there are inverted tets. To find out where things are going wrong he tried to use the volume expression & look for negative volumes - but it appears VisIt is being too smart here and fixing the inverted tets somewhere in the pipeline. For debugging he wants a version of the volume expression that can identify this case.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 36
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Add some path to tease out negative volume tets.
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated: 07/06/2010 07:43 pm
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 2 - Rare
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008918cqsubmitter: Cyrus Harrisoncqsubmitdate: 04/10/09 Hank Shay has some data where the simulation says there are inverted tets. To find out where things are going wrong he tried to use the volume expression & look for negative volumes - but it appears VisIt is being too smart here and fixing the inverted tets somewhere in the pipeline. For debugging he wants a version of the volume expression that can identify this case.

Comments:
The desired solution is to add an argument to the volume expression that allows a user to override the default behavior when they want to use the expression to debug inverted tets.

slice and clip filters do not preserve ghost node information

cqid: VisIt00007613cqsubmitter: Mark Millercqsubmitdate: 12/04/06 I rated this as common becuase with the recent change to Mili plugin (which we maybe should back of off), we'll have a lot of meshes with ghost nodes. Open m_plot.miliPut up mesh plot of mesh1_no_free_nodes.Go to last timestep.Slice it. Now, you see contributions to themesh from ghost nodes.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 13
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: slice and clip filters do not preserve ghost node information
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:13 pm
Updated:
Likelihood: 4 - Common
Severity: 4 - Crash / Wrong Results
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00007613cqsubmitter: Mark Millercqsubmitdate: 12/04/06 I rated this as common becuase with the recent change to Mili plugin (which we maybe should back of off), we'll have a lot of meshes with ghost nodes. Open m_plot.miliPut up mesh plot of mesh1_no_free_nodes.Go to last timestep.Slice it. Now, you see contributions to themesh from ghost nodes.

Comments:

Consolidate ASCII input to uber plugin

We have several plugins supporting ASCII input; Curve2D, XYZ, PlainText probably others. They all have to deal with similar issues, bad chars, overflow, creation of mesh or curve objects, read options, etc.

We should consoidate all this functionality to a single plugin with various options

  • delimiter char can be specified in file
  • can define point meshes in 2 and 3D and/or curves
  • maybe can take a config file that tells VisIt how to interpret the columns of data
  • can name columns
  • can name segments
  • can deal with compressed file(s)
  • doesn't read the darn file into the mdserver (several of them we currently have do)
  • can do things like skipping/averaging points (when there are millions to read)
  • can handle the data in modest number of parallel tasks including doing I/O in the file in parallel well

We don't really handle big curve data too well. We take forever to read it. We don't scale with it because it is treated as single block (though multi-block curves are now supported), we store it in memory of mdserver and engine, and viewer (as its renderable form). It can be several minutes to get an image for a curve of 100 million points. We ought to be able to handle that case ok.

git lfs fails when cloned with ssh

When cloned with ssh, git lfs env can have an unknown endpoint. This can be resolved by updating the .git/config file:

git config lfs.url = "https://github.com/visit-dav/visit.git/info/lfs"

However, .git/config is a local file, not tracked in our repo. The internet says that this can be resolved by adding and tracking a .lfsconfig file, like this:

git config -f .lfsconfig lfs.url https://github.com/visit-dav/visit.git/info/lfs
git add .lfsconfig

This ticket is to add this file for those who clone via ssh and run into this problem (like me) and check that it doesn't mess with anyone's git lfs configuration.

Label plot format needs Enter before apply to take effect.

cqid: VisIt00008983cqsubmitter: Brad Whitlockcqsubmitdate: 10/07/09 An external user had trouble setting the Label format in the Label plot window. It turns out that after entering the format, you must press Enter before clicking Apply. This was with 1.12 so I don't know if it's been fixed in the Qt4 trunk.

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 47
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Label plot format needs Enter before apply to take effect.
Assigned to: Eric Brugger
Category: -
Target version: 2.1
Author: Cyrus Harrison
Start:
Due date:
% Done: 100%
Estimated time: 2.00 hours
Created: 06/21/2010 07:15 pm
Updated: 08/24/2010 02:21 pm
Likelihood: 2 - Rare
Severity: 2 - Minor Irritation
Found in version: 2.0.0
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
cqid: VisIt00008983cqsubmitter: Brad Whitlockcqsubmitdate: 10/07/09 An external user had trouble setting the Label format in the Label plot window. It turns out that after entering the format, you must press Enter before clicking Apply. This was with 1.12 so I don't know if it's been fixed in the Qt4 trunk.

Comments:

Path required in cmfe filenames?

cqid: VisIt00008047cqsubmitter: Brad Whitlockcqsubmitdate: 05/18/07 The cmfe expressions seem to need the database path. VisIt stores filenames using the entire path internally so perhaps the lack of path in the filename prevents cmfe from finding the right database. Richard Sharp complains that he is "in that directory so VisIt should find the files". dagobah 1016% mkdir richarddagobah 1017% cd richard/dagobah 1018% ln s ../wave/wave0000.silo A000.silodagobah 1019% ln s ../wave/wave0010.silo A010.silodagobah 1020% ln s ../wave/wave0020.silo A020.silodagobah 1021% ln s ../wave/wave0030.silo A030.silodagobah 1022% ln s ../wave/wave0200.silo B000.silodagobah 1023% ln s ../wave/wave0210.silo B010.silodagobah 1024% ln s ../wave/wave0220.silo B020.silodagobah 1025% ln s ../wave/wave0230.silo B030.silo 1. Open A**.silo database2. A_minus_B = pressure - pos_cmfe(<B**.silo database:pressure>, quadmesh, 1.)3. Create Pseudocolor of A_minus_B4. Draw Pseudocolor: ()viewer: The file "B*.silo database" does not exist. This expression works and is what we want. It must need the path.pressure - pos_cmfe(</home/whitlocb/data/richard/B*.silo database:pressure>, quadmesh, 1.)

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 34
Status: Pending
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: Path required in cmfe filenames?
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood: 4 - Common
Severity: 3 - Major Irritation
Found in version: < 1.12
Impact:
Expected Use:
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008047cqsubmitter: Brad Whitlockcqsubmitdate: 05/18/07 The cmfe expressions seem to need the database path. VisIt stores filenames using the entire path internally so perhaps the lack of path in the filename prevents cmfe from finding the right database. Richard Sharp complains that he is "in that directory so VisIt should find the files". dagobah 1016% mkdir richarddagobah 1017% cd richard/dagobah 1018% ln s ../wave/wave0000.silo A000.silodagobah 1019% ln s ../wave/wave0010.silo A010.silodagobah 1020% ln s ../wave/wave0020.silo A020.silodagobah 1021% ln s ../wave/wave0030.silo A030.silodagobah 1022% ln s ../wave/wave0200.silo B000.silodagobah 1023% ln s ../wave/wave0210.silo B010.silodagobah 1024% ln s ../wave/wave0220.silo B020.silodagobah 1025% ln s ../wave/wave0230.silo B030.silo 1. Open A**.silo database2. A_minus_B = pressure - pos_cmfe(<B**.silo database:pressure>, quadmesh, 1.)3. Create Pseudocolor of A_minus_B4. Draw Pseudocolor: ()viewer: The file "B*.silo database" does not exist. This expression works and is what we want. It must need the path.pressure - pos_cmfe(</home/whitlocb/data/richard/B*.silo database:pressure>, quadmesh, 1.)

Comments:

xml tools should handle MapNode

cqid: VisIt00008973cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 09/28/09 Would be nice if our xmltools could handle MapNodes.Would make creating changeable state objects easier(like annotation objects).

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 49
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: xml tools should handle MapNode
Assigned to: -
Category: -
Target version: -
Author: Cyrus Harrison
Start:
Due date:
% Done: 0%
Estimated time:
Created: 06/21/2010 07:15 pm
Updated:
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: DOE/ASC
Description:
cqid: VisIt00008973cqsubmitter: Kathleen S. Bonnellcqsubmitdate: 09/28/09 Would be nice if our xmltools could handle MapNodes.Would make creating changeable state objects easier(like annotation objects).

Comments:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.