PHASTA Wiki - User contributions [en]

ParaView/Visualizing PHASTA with SyncIO

2017-12-15T18:14:53Z

Cwsmith:

== Running Paraview on a viz Node ==

portal1 $ vglconnect viz002
viz002 $ soft add +paraview-5.2.0-gnu-ompi
viz002 $ vglrun paraview

== Defining the PHASTA Input ==

There are two extensions:

pht -> POSIX files

phts -> SyncIO files

=== A Two Phase Case ===

An example phts file for a two phase, four process case using one syncio file is below.

<?xml version="1.0" ?>
<PhastaMetaFile number_of_pieces="4"
number_of_files="1">
<GeometryFileNamePattern pattern="4-procs_case-SyncIO-1/geombc-dat.%d"
has_piece_entry="1"
has_time_entry="0"/>
<FieldFileNamePattern pattern="4-procs_case-SyncIO-1/restart-dat.%d.%d"
has_piece_entry="1"
has_time_entry="1"/>
<TimeSteps number_of_steps="1"
auto_generate_indices="1"
start_index="0"
increment_index_by="1"
start_value="0"
increment_value_by="1">
</TimeSteps>
<Fields number_of_fields="5">
<Field paraview_field_tag="velocity"
phasta_field_tag="solution"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="pressure"
phasta_field_tag="solution"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="scr1"
phasta_field_tag="solution"
start_index_in_phasta_array="5"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="scr2"
phasta_field_tag="solution"
start_index_in_phasta_array="6"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="temperature"
phasta_field_tag="solution"
start_index_in_phasta_array="4"
number_of_components="1"
data_dependency="0"
data_type="double"/>
</Fields>
</PhastaMetaFile>

=== A Single Phase Case ===

An example phts file for a single phase, 2048 process case using 16 syncio files is below.

<?xml version="1.0" ?>
<PhastaMetaFile number_of_pieces="2048"
number_of_files="16">
<GeometryFileNamePattern pattern="2048-procs_case/geombc-dat.%d"
has_piece_entry="1"
has_time_entry="0"/>
<FieldFileNamePattern pattern="2048-procs_case/restart-dat.%d.%d"
has_piece_entry="1"
has_time_entry="1"/>
<TimeSteps number_of_steps="1"
auto_generate_indices="1"
start_index="800"
increment_index_by="1"
start_value="800"
increment_value_by="1">
</TimeSteps>
<Fields number_of_fields=“8">
<Field phasta_field_tag="errors"
paraview_field_tag="pde-res"
start_index_in_phasta_array="0"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="errors"
paraview_field_tag="rms-vel"
start_index_in_phasta_array="6"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="ybar"
paraview_field_tag="EVbar"
start_index_in_phasta_array="12"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="solution"
paraview_field_tag="u"
start_index_in_phasta_array="1"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="solution"
paraview_field_tag="pressure"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double”/>
<Field phasta_field_tag="solution"
paraview_field_tag="eddy visocity"
start_index_in_phasta_array="5"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="dwal"
paraview_field_tag="dwal"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="vorticity"
paraview_field_tag="Q"
start_index_in_phasta_array="4"
number_of_components="1"
data_dependency="0"
data_type="double"/>
</Fields>
</PhastaMetaFile>

ParaView/Visualizing PHASTA with SyncIO

2017-12-15T18:13:16Z

Cwsmith: Created page with "## Running Paraview on a viz Node ## portal1 $ vglconnect viz002 viz002 $ soft add +paraview-5.2.0-gnu-ompi viz002 $ vglrun paraview ## Defining the PHASTA Input ## T..."

## Running Paraview on a viz Node ##

portal1 $ vglconnect viz002
viz002 $ soft add +paraview-5.2.0-gnu-ompi
viz002 $ vglrun paraview

## Defining the PHASTA Input ##

There are two extensions:

pht -> POSIX files

phts -> SyncIO files

### A Two Phase Case ###

An example phts file for a two phase, four process case using one syncio file is below.

<?xml version="1.0" ?>
<PhastaMetaFile number_of_pieces="4"
number_of_files="1">
<GeometryFileNamePattern pattern="4-procs_case-SyncIO-1/geombc-dat.%d"
has_piece_entry="1"
has_time_entry="0"/>
<FieldFileNamePattern pattern="4-procs_case-SyncIO-1/restart-dat.%d.%d"
has_piece_entry="1"
has_time_entry="1"/>
<TimeSteps number_of_steps="1"
auto_generate_indices="1"
start_index="0"
increment_index_by="1"
start_value="0"
increment_value_by="1">
</TimeSteps>
<Fields number_of_fields="5">
<Field paraview_field_tag="velocity"
phasta_field_tag="solution"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="pressure"
phasta_field_tag="solution"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="scr1"
phasta_field_tag="solution"
start_index_in_phasta_array="5"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="scr2"
phasta_field_tag="solution"
start_index_in_phasta_array="6"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field paraview_field_tag="temperature"
phasta_field_tag="solution"
start_index_in_phasta_array="4"
number_of_components="1"
data_dependency="0"
data_type="double"/>
</Fields>
</PhastaMetaFile>

### A Single Phase Case ###

An example phts file for a single phase, 2048 process case using 16 syncio files is below.

<?xml version="1.0" ?>
<PhastaMetaFile number_of_pieces="2048"
number_of_files="16">
<GeometryFileNamePattern pattern="2048-procs_case/geombc-dat.%d"
has_piece_entry="1"
has_time_entry="0"/>
<FieldFileNamePattern pattern="2048-procs_case/restart-dat.%d.%d"
has_piece_entry="1"
has_time_entry="1"/>
<TimeSteps number_of_steps="1"
auto_generate_indices="1"
start_index="800"
increment_index_by="1"
start_value="800"
increment_value_by="1">
</TimeSteps>
<Fields number_of_fields=“8">
<Field phasta_field_tag="errors"
paraview_field_tag="pde-res"
start_index_in_phasta_array="0"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="errors"
paraview_field_tag="rms-vel"
start_index_in_phasta_array="6"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="ybar"
paraview_field_tag="EVbar"
start_index_in_phasta_array="12"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="solution"
paraview_field_tag="u"
start_index_in_phasta_array="1"
number_of_components="3"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="solution"
paraview_field_tag="pressure"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double”/>
<Field phasta_field_tag="solution"
paraview_field_tag="eddy visocity"
start_index_in_phasta_array="5"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="dwal"
paraview_field_tag="dwal"
start_index_in_phasta_array="0"
number_of_components="1"
data_dependency="0"
data_type="double"/>
<Field phasta_field_tag="vorticity"
paraview_field_tag="Q"
start_index_in_phasta_array="4"
number_of_components="1"
data_dependency="0"
data_type="double"/>
</Fields>
</PhastaMetaFile>

ParaViewOnTukey

2017-12-15T17:45:02Z

Cwsmith: /* Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on the Tukey login node */

== Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on portal0 at Colorado ==
http://fluid.colorado.edu/~mrasquin/Documents_HIDE/Tukey/ParaviewOnTukeyFromPortal0/index.html

This video can be copied from /users/mrasquin/public_html/Documents_HIDE/Tukey/ParaviewOnTukeyFromPortal0 on the viz nodes.

== Video Tutorial about how to run a pvserver-syncio in parallel on the Tukey visualization nodes and connect the pvserver to a ParaView Gui running on the Tukey login node ==
https://fluid.colorado.edu/~mrasquin/phasta/ParaViewOnTukey/index.html

This video can be copied from /users/mrasquin/public_html/Tukey/ParaviewOnTukeyThroughVNC on the viz nodes.

Note that because vncserver on the Tukey head node does not support OpenGL, this method does not allow the export of png pictures from the ParaView Gui. Indeed, the result will be completely fuzzy. The first method is therefore strongly recommended.

Work Plan In Memory Adapt

2015-11-20T23:01:14Z

Cwsmith: /* Detailed Description of Phases */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data - done
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields - done
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR) - done
*phase5 replace UR with local adaptation - done
*phase6 loop and we are done - done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_[read|write] (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile_[read|write]

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these eight functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.cc which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into phio layer - hardcoded in phasta - see https://github.com/cwsmith/phastaChef/issues/17
## Move file name construction into - done
## Move query and init into phio_opefile_* - done
## Migrating all of PHASTA to use wrapper apis - done
#phase1
## Migrate string constructors into conditional for syncio - done
## Create posix counterparts and put them in the posix branch of conditional - done
## Debug to be sure that at least all tet meshes can be read with both posix/syncio - done
## Debug to make sure that files written are correct (two successive runs) - done
#phase2
## Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file - done
## Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing) - done
## Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote - done
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location - done
## Create ability to pass the descriptor of that memory location back to Chef - done
## Create ability for Chef to read adapt-fields when passed descriptor - done
## Invoke a UR with solution transfer and write files to confirm phase3 success - done
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale) - done
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut). - done

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-11-20T22:59:55Z

Cwsmith: /* Summary of Phases */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data - done
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields - done
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR) - done
*phase5 replace UR with local adaptation - done
*phase6 loop and we are done - done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_[read|write] (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile_[read|write]

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these eight functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.cc which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into phio layer - hardcoded in phasta - see https://github.com/cwsmith/phastaChef/issues/17
## Move file name construction into - done
## Move query and init into phio_opefile_* - done
## Migrating all of PHASTA to use wrapper apis - done
#phase1
## Migrate string constructors into conditional for syncio - done
## Create posix counterparts and put them in the posix branch of conditional - done
## Debug to be sure that at least all tet meshes can be read with both posix/syncio - done
## Debug to make sure that files written are correct (two successive runs) - done
#phase2
## Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:20:45Z

Cwsmith: /* Detailed Description of Phases */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_[read|write] (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile_[read|write]

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these eight functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.cc which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into phio layer - hardcoded in phasta - see https://github.com/cwsmith/phastaChef/issues/17
## Move file name construction into - done
## Move query and init into phio_opefile_* - done
## Migrating all of PHASTA to use wrapper apis - done
#phase1
## Migrate string constructors into conditional for syncio - done
## Create posix counterparts and put them in the posix branch of conditional - done
## Debug to be sure that at least all tet meshes can be read with both posix/syncio - done
## Debug to make sure that files written are correct (two successive runs) - done
#phase2
## Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:15:52Z

Cwsmith: /* phastaIO */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_[read|write] (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile_[read|write]

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these eight functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.cc which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:13:56Z

Cwsmith: /* Detailed Description of Phases */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:13:20Z

Cwsmith: /* Summary of Phases */

== Summary of Phases ==

*phase0 wrapper layer that supports both syncio and posix - done 7/20/2015
*phase1 PHASTA can read AND write both - done 7/22/2015
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:12:11Z

Cwsmith: /* preliminary design plan */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

Initially, <code>setIOparam()</code> counting of syncio files will be used to determine if sync or posix files will be used. If the count is zero then assume posix. Use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

Work Plan In Memory Adapt

2015-07-23T15:11:52Z

Cwsmith: /* preliminary design plan */

Work Plan In Memory Adapt

2015-07-23T15:09:25Z

Cwsmith: /* phastaIO */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

=== preliminary design plan ===
* use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
* push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix openfile, closefile, {read,write}X{header,datablock}

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

== preliminary design plan ==
* use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
* push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix openfile, closefile, {read,write}X{header,datablock}

Work Plan In Memory Adapt

2015-07-23T15:08:51Z

Cwsmith: /* Thorny Issues */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## extra write files. Seems to me that there should be either
### only 2 write_restart and write_field, or
### an init function and then only write_field
## dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## KEJ is still trying to sort out the roles of {query,init}phmpiio.
### query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### init is called for both reads and writes of syncio files

== preliminary design plan ==
* use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
* push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix openfile, closefile, {read,write}X{header,datablock}

Work Plan In Memory Adapt

2015-07-23T15:08:27Z

Cwsmith: /* THORNY ISSUES */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==Thorny Issues==

#phase0
## 1) extra write files. Seems to me that there should be either
### a) only 2 write_restart and write_field, or
### b) an init function and then only write_field
## 2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)
## 3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code
## 4) KEJ is still trying to sort out the roles of {query,init}phmpiio.
### a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
### b) init is called for both reads and writes of syncio files

== preliminary design plan ==
* use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
* push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix openfile, closefile, {read,write}X{header,datablock}

Work Plan In Memory Adapt

2015-07-23T15:06:29Z

Cwsmith: /* phastaIO */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

== Detailed Description of Phases ==

# phase0
## Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)
## Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.
### Move query and init into B)
## Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)
## Repeat 0.1-0.3 for writing of files
#phase1
## Migrate string constructors into conditional for syncio
## Create posix counterparts and put them in the posix branch of conditional
## make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)
## Debug to be sure that at least all tet meshes can be read with both posix/syncio
## Debug to make sure that files written are correct (two successive runs)
#phase2
## 2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file
## 2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)
## 2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote
#phase3
## Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location
## Create ability to pass the descriptor of that memory location back to Chef
## Create ability for Chef to read adapt-fields when passed descriptor
## Invoke a UR with solution transfer and write files to confirm phase3 success
#phase4
## Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)
#phase5
## Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

==THORNY ISSUES==

phase0

1) extra write files. Seems to me that there should be either

a) only 2 write_restart and write_field, or

b) an init function and then only write_field

2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)

3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code

4) KEJ is still trying to sort out the roles of {query,init}phmpiio.
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
b) init is called for both reads and writes of syncio files

preliminary design plan
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix
openfile, closefile, {read,write}X{header,datablock}

Work Plan In Memory Adapt

2015-07-23T15:02:34Z

Cwsmith: /* SUMMARY of phases */

== Summary of Phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

DETAIL

phase0

0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)

0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.

0.2' Move query and init into B)

0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)

0.4 Repeat 0.1-0.3 for writing of files

phase1

1.1 Migrate string constructors into conditional for syncio

1.2 Create posix counterparts and put them in the posix branch of conditional

1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)

1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio

1.4 Debug to make sure that files written are correct (two successive runs)

phase2

2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file

2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)

2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote

phase3

3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location

3.2 Create ability to pass the descriptor of that memory location back to Chef

3.3 Create ability for Chef to read adapt-fields when passed descriptor

3.4 Invoke a UR with solution transfer and write files to confirm phase3 success

phase4

4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)

phase5

5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

THORNY ISSUES

phase0

1) extra write files. Seems to me that there should be either

a) only 2 write_restart and write_field, or

b) an init function and then only write_field

2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)

3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code

4) KEJ is still trying to sort out the roles of {query,init}phmpiio.
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
b) init is called for both reads and writes of syncio files

preliminary design plan
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix
openfile, closefile, {read,write}X{header,datablock}

Work Plan In Memory Adapt

2015-07-23T15:02:21Z

Cwsmith:

== SUMMARY of phases ==

*phase0 clean syncio (almost there)
*phase1 PHASTA can read AND write both
*phase2 PHASTA runs after chef though an in-memory read of Chef's written in-memory data
*phase3 PHASTA writes its field back to chef and lets chef do a UR on its mesh and transfers fields
*phase4 bring that result back to phasta (so chef->PHASTA->chef-UR->PHASTA-UR)
*phase5 replace UR with local adaptation
*phase6 loop and we are done

== phastaIO ==

For the sake of discussion lets group phastaIO functions as follows

<pre>
init
open-close
read (readheader, readdatablock)
write (writeheader, writedatablock)
initalize
</pre>

To make the interface more simple, I propose, we push init into open and finalize into close. Furthermore I propose that we consider a wrapper layer approach
where the functions that the PHASTA workflow directly uses to perform IO are:

*phio_openfile_read (in addition to specializing filename string for particular library, this function can call queryphmpiio and initphmpiio in the case of syncio)
*phio_openfile_write (in addition to specializing filename string for particular library, this function can call initphmpiio in the case of syncio)
*phio_readheader
*phio_readdatablock
*phio_writeheader
*phio_writedatablock
*phio_closefile

These functions will be called by readnblk (and a few others) for reading and Write_restart (and a few clones) for writing. Principally, these 6 functions will be wrappers that take in partial strings and the usual arguments for their PhastaIO functions and then perform the necessary string specializations for the particular flavor of PhastaIO being used (e.g,, syncio or posix) before then ultimately calling the PhastaIO function (that already has a branching based on the two flavors). Cameron has proposed housing those seven wrappers in phIO.c which seems fine to me. Helper functions can go in the same file.

DETAIL

phase0

0.1 Move field string construction into C)- status: CWS has done this for syncio (top of routines so not yet in a syncio conditional but this is not necessary until phase1)

0.2 Move file name construction into B)- status: not started but I think CWS indicated it was basically same work as 0.1 so leaving that with him. Note we don’t want this in init (at least for restarts) because we init only once but possibly write multiple times and the filename changes.

0.2' Move query and init into B)

0.3 Migrating all of PHASTA to use 0.1 dev - status: CWS did it for readnblk.f and this built and ran (YAY), KEJ is migrating it to the balance of PHASTA (DONE I THINK)

0.4 Repeat 0.1-0.3 for writing of files

phase1

1.1 Migrate string constructors into conditional for syncio

1.2 Create posix counterparts and put them in the posix branch of conditional

1.3 make init and finalize functions that have a universal call but, via conditionals (likely posix just returns but syncio has stuff to do but we want the PHASTA side to look the same regardless of IO chosen)

1.3 Debug to be sure that at least all tet meshes can be read with both posix/syncio

1.4 Debug to make sure that files written are correct (two successive runs)

phase2

2.1 Create ability for Chef to write to memory location using posixIO pointed at a memory location instead of a file

2.2 Create ability to pass the descriptor of that memory location to PHASTA (I think it is safe to assume that since we are one “file” per part in both Chef and PHASTA that this is just the starting location of where Chef started writing)

2.3 Create ability to have phasta initialize itself with posix-based PHASTAIO reads from this in-memory file/state that Chef wrote

phase3

3.1 Create ability for PHASTA to write adapt-fields (solution, d2wall, error, ybar) using posix-based PHASTAIO writes to a memory location

3.2 Create ability to pass the descriptor of that memory location back to Chef

3.3 Create ability for Chef to read adapt-fields when passed descriptor

3.4 Invoke a UR with solution transfer and write files to confirm phase3 success

phase4

4.1 Should be trivial but have Chef write result of UR to a new memory location and pass descriptor to PHASTA to read and run again (comparing to file based version of the same which we are already doing at scale)

phase5

5.1 Demonstrate that we can do file based local adaptive refinement with Chef (I will let Dan and Cameron described the subtask developments here but am more than happy to help plan and assist in any way I can because we really need this capability…I am fine with ignoring/freezing boundary layers to get a working case going before taking on that much tougher nut).

THORNY ISSUES

phase0

1) extra write files. Seems to me that there should be either

a) only 2 write_restart and write_field, or

b) an init function and then only write_field

2) dwall currently has two modes (in restart or in a separate file….do we really need to preserve this)

3) usr.c opens restart to read saved projection vectors. Not a problem per se but might be better to read this while we have the restart already open so that the IO code is more compact. This may involve moving more leslib stuff forward in the code

4) KEJ is still trying to sort out the roles of {query,init}phmpiio.
a) query is called before file is read the first time (same file read again can get by without it e.g., readlesprojection reads restart a second time)
b) init is called for both reads and writes of syncio files

preliminary design plan
i) use setIOparam() to count syncio files. If count=0 then assume posix. use the count as a switch for file format everywhere (can be replaced later by agreed upon flag for file format...candidates: iotype= binary-posix, binary-mpiio instead of binary (not sure we want to preserve ascii unless it easy to do)
ii) push all init stuff into openfile so that there are only 6 functions that any users sees in phastaIO for either syncio or posix
openfile, closefile, {read,write}X{header,datablock}

SpaceClaim

2012-08-01T18:09:24Z

Cwsmith:

[[Category:Software]]
== Enabling mouse view controls ==
Button in top left -> SpaceClaim Options (bottom right)

[[File:SpaceClaim0.PNG|border|300px]]

'Navigation' -> Zoom -> Always

[[File:SpaceClaim.PNG|border|300px]]

SpaceClaim

2012-08-01T18:08:31Z

Cwsmith: /* Enabling mouse view controls */

== Enabling mouse view controls ==
Button in top left -> SpaceClaim Options (bottom right)

[[File:SpaceClaim0.PNG|border|300px]]

'Navigation' -> Zoom -> Always

[[File:SpaceClaim.PNG|border|300px]]

File:SpaceClaim.PNG

2012-08-01T18:05:21Z

Cwsmith: SpaceClaim options menu

SpaceClaim options menu

File:SpaceClaim0.PNG

2012-08-01T18:04:29Z

Cwsmith: space claim menu button

space claim menu button

SpaceClaim

2012-08-01T18:03:57Z

Cwsmith: Created page with "== Enabling mouse view controls == button in top left -> SpaceClaim Options -> Navigation (on left side) -> Zoom -> Always"

== Enabling mouse view controls ==
button in top left -> SpaceClaim Options -> Navigation (on left side) -> Zoom -> Always