Moved to Verification of workflow porting from Foster to Fitzroy

What can Paraview do for me?

Paraview is a visualization software capable of reading almost any kind of input file and do 2D and 3D rendering of scientific data.One can go from a basic CSV file to more complex formats like the VTK based ones (http://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf).

It allows you to improve the presentation of your results for scientific and general public.

(I cannot upload files  so I have some images here: https://drive.google.com/open?id=0B3o2OfQ3KYoqWS1kOTJ1RTZoZzQ)

Some useful ideas:

• It can add tracers to vectorial quantities
• Break a 3D domain into planes to show what is happening with some of the quantities
• Paraview can actually do calculations with the vectors on your results: For example in my case, after a very long simulation I needed a quantity that I did not simulate, the enstrophy. However, I had the vorticity and its integral gave me the result I wanted.
• Add streamlines

Animations, oh yeah!

Perhaps one of the most coolest awesomest feature in Paraview is to make animations quite easily.

In order to animate something you can either provide:

• A set of input files that are numbered sequentially. In that case we can get a temporal animation.
• A single file. In this case we can animate the camera to visit certain regions of the rendered results in order to show something interesting that is happening
  • In this example I also used a feature called "save state..." which will write all your interactions with Paraview in the current session to disk. It is very useful to load a particular set of interactions and improve them.

Paraview and OpenSees

• The PVD recorder works, yay!
• The PVD recorder does not work on parallel, duh!
• However, we can make a very simple python script to translate the input + outputs into a suitable format. I was almost there last week, but when trying to re-write the code to be nicer I erased most of it. Anyways, it can be done and it can be an alternative to the recorder.

Some last thoughts

• Paraview works fine, is free but the learning curve may be difficult
• Sung and I can always try to help into getting some nice animations
• "Paraview works on parallel" is kind of a lie, at least in my past life experience.
• A lot of resources around the internets!

Meeting held on the 30 Sep 2016 at 9:30 NZDT

Proposed Agenda

1. Introduction
2. Background: QuakeCoRE SeisFinder
3. SCEC experience
   
   • Overview
   • Size
   • Number of visitors and who they are expected to be (general public?)
   • HW, SW, network?
   • Issues around using SQL for this particular type of project. Advantages?
   • Have they considered any other alternative that does not use SQL? For example Hadoop (large storage, map-reduce operations)  https://github.com/Esri/gis-tools-for-hadoop
   • Maintenance: how many people need to be working on the project in order for it to remain usable.
4. QuakeCoRE requirement
   

   • Support for large size data

   • Quick response

   • Support for many concurrent queries :  http://stackoverflow.com/questions/16628329/hdf5-concurrency-compression-i-o-performance

   • Flexible/scalable to add more fields for retrieval

   • Support for geographic data type : Need to query "nearest" points.

   • hosting (external/internal)

5. Others
   • QuakeCoRE: Workflow. Currently with loadleveler multistep job. Will be incorporating cylc.  https://cylc.github.io/cylc/
     
     

Notes after the meeting

• SCEC database (DB) has a large number of seismic information, in the order of 22 Billion seismic entries. They have started seeing increased query times. They use MySQL as the backend. The DB runs on a grunty machine with 128 GB of RAM and 24 cores under Fedora 24.They also have another machine that is not public facing with smaller specs. Other points here:
  
  • Query performance has increased as the DB has gotten bigger (~ 4Tb)
  • They will try to reduce the size of the most problematic tables to improve performance.
  • They want to split the current huge DB into two: Production DB (containing only latests analysis) and a read-only  SQLlite based DB with less used data.
• Their database is not for the public at this point, it is mostly used by researchers. The usage pattern is quite bursty and not constant. It depends mainly on the researchers that require the data.
• Besides the performance issues they have noticed with MySQL, other issues related to be noted are:
  • Backup will increase as the DB size increases
  • Updating MySQL is a complex operation. Nevertheless, it is always a good idea to update for bug fixes/performance improvements/new features.
  • Note that they have dedicated staff to administer the machine and the DB
• Thinking about a solution that does not use MySQL is not feasible, as they have build a stack on top of it that relies on the DB backend to provide certain features.
  • We should be cautious in analyzing our requirements so that we choose a suitable DB for our needs as well.
• When discussing about Hadoop, Scott's intake is that it does not suit a querying serving problem as the one they face. On top of it, it requires a custom filesystem and they do not think that their. Basically they have not found a solution that would be so appealing that they would move from the current one.
• They seem interested in using HDF5 as a standard for some of the output produced by the codes they use, as currently they have several custom binary formats.
• Their workflow uses Pegasus (https://pegasus.isi.edu/)

Sep 21, 2016

Brendon Bradley, Sung Bae, Hoby Razafindrakoto, Seokho Jeong, Viktor Polak, Sharmila Savarimuthu, Kevin Foster, Chris De la Torre, Ethan Thomson, Chris McGann

I. GM Simulation

1. Chris De la Torre : Python code development
2. Hoby: Lessons from SCEC

II. Workflow

1. Current progress

1. SeisFinder (Viktor/Sharmla) : Demo, Google Map API. Viktor to investigate KML export.
2. StatGrid validation (Sung) : Issues, solutions
   • Current issue : 400m statgrid output too large. Not enough disk space for DB conversion (P7 has 2x135Gb only)
   • Plan:
     
     • Canterbury instead of SI (same resolution as statgrid) and comparison : Just to complete validation.
     • Talk to UC HPC for disk space.
     • (To do) BB suggests Sung to consult Scott Cahallagan (SCEC) re. DB tools and develop a solution compatible to SCEC.
     • Q : a method to compare two seismograms? (To do) To discuss with Hoby offline.
3. OpenSees (Daniel) POWER7 SW stack for OpenSees development. Will start collaboration with Alex Pletzer from NeSI. Seokho to point to a paper re. OpenSEES scalability issue.
4. HW purchase (Viktor). Quote from Cyclone, specs.

2. New Ideas

• Visualisaton (Sung) - http://scecvdo.usc.edu/  : SCEC-VDO. Shakemap animation not currently possible, and perhaps not ideal for automated 3D animation production. Yet a nice platform for data visualisation potentially beneficial for TB3.
• Non-uniform grid of stations over SI.
• (To do) Sung to test SCEC-VDO and explore possibility of extending it, and talk to Matthew Hughes and exchange ideas.

3. New tasks

test