-
The www2.cesm.ucar.edu website is currently down for maintenance
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
cam5 FV dynamical core
- Thread starter dan_lipsa@kitware_com
- Start date
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
dan_lipsa@kitware_com
Member
We would definitely want to try this! Do you have an approximate release date for pio2?
Thank you
Thank you
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
Hopefully by the end of the year. If I understand what you are trying to do, and I'm not sure yet that I do it would involve modifying the API a bit so that you can intercept the data between the rearrangement and the write steps. We can discuss details via email if you like. - Jim
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
dan_lipsa@kitware_com
Member
Hi Jim,The goal of ParaView Catalyst is to enable post-processing on the compute nodes. This contrasts with the traditional post-processing workflow: save derived data, move the data on a different machine, create visualizations with it. For this we link a slimmed down version of ParaView to the simulation code, pass the data on each compute node to the ParaView running on that node and perform post-processing using any VTK/ParaView pipeline. The pipeline is written in Python. We can save processed datasets, visualizations or we can send processed data to a remote ParaView.The challenge for cam5 (fv, cam5, trop_mam3) is that computational load balance (chunking) that is performed by the physics module seems to imply spatial non-coherence between data stored on different compute nodes. (columns are not next to each other on one compute node).Our current project is limited in goals (and funds) so I will not pursue the PIO route further at the moment.Just out of curiosity though, why do you want to build larger blocks on the compute nodes? This will help us for visualization, but the physics module does not seem to need that.Thank you,
spatial non-coherence between data stored on different compute nodesI should point out that this is something of an understatement; the most common load balancing strategies try to deliberately minimize spatial coherence, in order to improve the chances that each task has a mix of columns from "expensive" regions and those from "cheap" regions. E.g. day is more expensive than night, cloudy is more expensive than clear sky.