Documentation - User contributions [en]

File:Slice-sn02-439.png

2013-07-18T14:33:37Z

Razoumov:

File:Hi-sn02-439.png

2013-07-18T14:32:57Z

Razoumov:

File:Sh1-zoom.png

2013-07-18T14:32:09Z

Razoumov:

File:L1-329.jpg

2013-07-18T14:31:30Z

Razoumov:

File:Frame160950215.png

2013-07-18T14:14:00Z

Razoumov:

File:Frame160950101.png

2013-07-18T14:13:44Z

Razoumov:

File:Frame160950000.png

2013-07-18T14:13:27Z

Razoumov:

File:Co-cristallize.jpg

2013-07-18T14:08:02Z

Razoumov:

File:CdTe1.jpg

2013-07-18T14:07:16Z

Razoumov:

File:AuPt1.jpg

2013-07-18T13:53:42Z

Razoumov:

GEANT4

2013-05-22T20:29:23Z

Razoumov:

{{Software
|package_name=GEANT4
|package_description=Suite of programs for the simulation of the passage of particles through matter
|package_idnumber=59
}}
The latest version of geant4 (9.6.1) is installed on CentOS clusters under /opt/sharcnet/geant4/9.6.1/gcc .

Geant4 comes with many examples useful for testing purposes. You can start with a simple test. For instance, here are the steps to compile and run an analysis example A01 in ~/testing directory inside your home directory:

module unload intel
module load gcc/4.5.3
module load geant4/gcc/9.6.1
export G4WORKDIR=~/testing
cp -a /opt/sharcnet/geant4/9.6.1/gcc/examples/extended/analysis/A01 $G4WORKDIR/A01
source /opt/sharcnet/geant4/9.6.1/gcc/share/Geant4-9.6.1/geant4make/geant4make.sh
export CXX=g++
cd $G4WORKDIR/A01
make
sqsub -q serial -r 5m -o output.log ../bin/Linux-g++/A01app

Note that geant4 makefiles will omit the environment variable $LD_RUN_PATH which has a path to gcc libraries, instead encoding only its own path to the application library you are building ($G4WORKDIR/tmp/Linux-g++/A01app in our example), so we need to set LD_LIBRARY_PATH by hand before running geant4 as illustrated by the example above.

==References==

o Geant4 Homepage<br>
http://geant4.web.cern.ch/geant4/

o Online User Documentation<br>
http://geant4.web.cern.ch/geant4/support/userdocuments.shtml

Talk:ILOGCPLEX

2013-02-08T00:53:50Z

Razoumov: Blanked the page

GEANT4

2012-10-26T21:50:19Z

Razoumov:

{{Software
|package_name=GEANT4
|package_description=Suite of programs for the simulation of the passage of particles through matter
|package_idnumber=59
}}
The latest version of geant4 (9.5) is installed on CentOS clusters under /opt/sharcnet/geant4/9.5/gcc .

Geant4 comes with many examples useful for testing purposes. You can start with a simple test. For instance, here are the steps to compile and run an analysis example A01 in ~/testing directory inside your home directory:

module unload intel
module load gcc/4.5.3
module load geant4/gcc/9.5
export G4WORKDIR=~/testing
cp -a /opt/sharcnet/geant4/9.5/gcc/examples/extended/analysis/A01 $G4WORKDIR/A01
source /opt/sharcnet/geant4/9.5/gcc/share/Geant4-9.5.0/geant4make/geant4make.sh
export CXX=g++
cd $G4WORKDIR/A01
make # LD_RUN_PATH is ignored by this makefile, so need to set LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/opt/sharcnet/gcc/4.5.3/lib64:$LD_LIBRARY_PATH
sqsub -q serial -r 5m -o output.log ../bin/Linux-g++/A01app

Note that geant4 makefiles will omit the environment variable $LD_RUN_PATH which has a path to gcc libraries, instead encoding only its own path to the application library you are building ($G4WORKDIR/tmp/Linux-g++/A01app in our example), so we need to set LD_LIBRARY_PATH by hand before running geant4 as illustrated by the example above.

GEANT4

2012-10-26T21:46:36Z

Razoumov:

{{Software
|package_name=GEANT4
|package_description=Suite of programs for the simulation of the passage of particles through matter
|package_idnumber=59
}}

The latest version of geant4 (9.5) is installed on CentOS clusters under /opt/sharcnet/geant4/9.5/gcc . We also have the older version 4.9.1 installed on some systems, but it is no longer updated, so for the newest geant4 please log in to the CentOS clusters.

Geant4 comes with many examples useful for testing purposes. You can start with a simple test. For instance, here are the steps to compile and run an analysis example A01 in ~/testing directory inside your home directory:

module unload intel/11.0.083
module load gcc/4.5.3
module load geant4/gcc/9.5
export G4WORKDIR=~/testing
cp -a /opt/sharcnet/geant4/9.5/gcc/examples/extended/analysis/A01 $G4WORKDIR/A01
source /opt/sharcnet/geant4/9.5/gcc/share/Geant4-9.5.0/geant4make/geant4make.sh
export CXX=g++
cd $G4WORKDIR/A01
make # LD_RUN_PATH is ignored by this makefile, so need to set LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/opt/sharcnet/gcc/4.5.3/lib64:$LD_LIBRARY_PATH
sqsub -q serial -r 5m -o output.log ../bin/Linux-g++/A01app

Note that geant4 makefiles will omit the environment variable $LD_RUN_PATH which has a path to gcc libraries, instead encoding only its own path to the application library you are building ($G4WORKDIR/tmp/Linux-g++/A01app in our example), so we need to set LD_LIBRARY_PATH by hand before running geant4 as illustrated by the example above.

File:Volume1.png

2011-03-14T23:27:36Z

Razoumov: example of ParaView visualization

example of ParaView visualization

File:Volume.png

2010-12-01T22:33:31Z

Razoumov: uploaded a new version of "File:Volume.png": NetCDF sample data for ParaView

paraview window with simple visualization

File:Volume.png

2010-12-01T16:14:25Z

Razoumov: paraview window with simple visualization

paraview window with simple visualization

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T17:12:42Z

Razoumov: /* Safe physics assumptions */

Project Title: '''Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres '''

Project originators:
*Howard Barker, Environment Canada
*Jacon Cole, Environment Canada
*Philip Austin, UBC

SHARCNET programming support:
*Pawel Pomorski
*Alex Razoumov

The goal of this project is to modify an existing radiative transfer code (one of the components of climate and weather modelling used by the EC group) to make it fully parallel. The code uses a Monte Carlo approach to inject photons into the domain studied and compute their propagation.

The approach of the initial code is to supply each processor with the entire spatial domain and inject N photons per each parallel processor. This approach does result in a parallel speedup but suffers from memory limitations. Thus the first improvement to the code will be to decompose the spatial domain into subdomains which will be assigned to individual processors. This will require adding code to handle photons transferring between domains as they cross the boundary.

Once that is done, the second stage of the project will be to improve the above approach to ensure good load balancing between processors.

==Safe physics assumptions==

# Radiation propagates at the finite speed "c", so strictly speaking the equation of radiative transfer should include a time-dependent advection term (differential transfer equation) or the "retarded" energy (integral transfer equation). Our assumption is that "c" is so large that all changes in the radiation field can be assumed instantaneous, and those "c"-dependent terms can be dropped.
# The conservation equations of radiation hydrodynamics describe conservation of mass, momentum, energy. Ideally, they should be solved in one (perhaps, implicit) update. Operator-splitting them into two steps (hydrodynamics and transfer) is good enough for this problem, but it's worth keeping in mind that it's an approximation.

==Approximations that we should worry about==

# It is assumed that all variations in matter properties caused by radiation -- heating and the resulting changes in opacity/emissivity -- are not fast, i.e. they happen on a fluid flow timescale (or shorter). Therefore, these changes can be computed in the hydrodynamical update. I suspect in the cloud problem many radiation-driven changes happen on a timescale dictated by microphysics of radiation-matter interaction that is often very short, e.g., a cloud can be heated or evaporated by radiation before it can adjust hydrodynamically. This means that one needs to do radiative transfer/microphysics updates continuously throughout the hydrodynamical timestep, as opposed to doing it once per timestep. There are two methods: doing subcycling (transfer-microphysics-transfer-microphysics-...), or doing a simultaneous implicit solve.
# With Monte Carlo transfer the stochastic error goes down as 1/sqrt(numberOfPhotons), in other words, shooting 1000 times more photons will only lower the errors by a factor of ~30. In order to have a solution that is accurate to 8-9 significant digits, how many photons one would need to propagate at each timestep, 1e20? This is why proper discretization of the transfer equation in all dimensions (3 spatial coordinates, two angles, frequency) is vastly superior to Monte Carlo for error control. There are many methods -- ray tracing, direct Boltzmann solver, and various approximations (variable Eddington tensors, moment-limited approximations) -- but they clearly go well beyond the scope of this programming project. As a sanity check with Monte Carlo, we should be aware of the solution accuracy, e.g. how many photons do we need to launch to have 1% (or 1e-4, 1e-6) accuracy in the heating rates in each cell. Consequently, this number of photons will influence not only the CPU time, but also the amount of communication between the processors/nodes. While pursuing decent accuracy on larger grids, the problem can be quickly dominated by passing photon buffers between processors and the associated MPI bottlenecks.
# Domain decomposition of radiative transfer might present its own problems. For example, if there are any radiation-driven fronts (I am thinking about ionization fronts in astrophysics, but coupling radiation to hydro might give rise to its own instabilities and fronts propagating at finite speeds), the order in which photons are passed between processors may become important. For example, the domain on the left may or may not have some important instability that will affect transfer in the domain on the right, on the timescale faster than the fluid flow. Then doing transfer in the domain on the right may be a waste of CPU time, until we have the solution from the domain on the left. Couple that with the fact that there is no left and right, but two angles (theta, phi) describing the direction of photon propagation, and you'll see how complex this problem can become.

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T17:12:02Z

Razoumov: /* Safe physics assumptions */

Project Title: '''Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres '''

Project originators:
*Howard Barker, Environment Canada
*Jacon Cole, Environment Canada
*Philip Austin, UBC

SHARCNET programming support:
*Pawel Pomorski
*Alex Razoumov

The goal of this project is to modify an existing radiative transfer code (one of the components of climate and weather modelling used by the EC group) to make it fully parallel. The code uses a Monte Carlo approach to inject photons into the domain studied and compute their propagation.

The approach of the initial code is to supply each processor with the entire spatial domain and inject N photons per each parallel processor. This approach does result in a parallel speedup but suffers from memory limitations. Thus the first improvement to the code will be to decompose the spatial domain into subdomains which will be assigned to individual processors. This will require adding code to handle photons transferring between domains as they cross the boundary.

Once that is done, the second stage of the project will be to improve the above approach to ensure good load balancing between processors.

==Safe physics assumptions==

# Radiation propagates at the finite speed "c", so strictly speaking the equation of radiative transfer should include a time-dependent advection term (differential transfer equation) or the "retarded" energy (integral transfer equation). The working (and pretty safe) assumption is that "c" is so large that all changes in the radiation field can be assumed instantaneous, and those "c"-dependent terms can be dropped.
# The conservation equations of radiation hydrodynamics describe conservation of mass, momentum, energy. Ideally, they should be solved in one (perhaps, implicit) update. Operator-splitting them into two steps (hydrodynamics and transfer) is good enough for this problem, but it's worth keeping in mind that it's an approximation.

==Approximations that we should worry about==

# It is assumed that all variations in matter properties caused by radiation -- heating and the resulting changes in opacity/emissivity -- are not fast, i.e. they happen on a fluid flow timescale (or shorter). Therefore, these changes can be computed in the hydrodynamical update. I suspect in the cloud problem many radiation-driven changes happen on a timescale dictated by microphysics of radiation-matter interaction that is often very short, e.g., a cloud can be heated or evaporated by radiation before it can adjust hydrodynamically. This means that one needs to do radiative transfer/microphysics updates continuously throughout the hydrodynamical timestep, as opposed to doing it once per timestep. There are two methods: doing subcycling (transfer-microphysics-transfer-microphysics-...), or doing a simultaneous implicit solve.
# With Monte Carlo transfer the stochastic error goes down as 1/sqrt(numberOfPhotons), in other words, shooting 1000 times more photons will only lower the errors by a factor of ~30. In order to have a solution that is accurate to 8-9 significant digits, how many photons one would need to propagate at each timestep, 1e20? This is why proper discretization of the transfer equation in all dimensions (3 spatial coordinates, two angles, frequency) is vastly superior to Monte Carlo for error control. There are many methods -- ray tracing, direct Boltzmann solver, and various approximations (variable Eddington tensors, moment-limited approximations) -- but they clearly go well beyond the scope of this programming project. As a sanity check with Monte Carlo, we should be aware of the solution accuracy, e.g. how many photons do we need to launch to have 1% (or 1e-4, 1e-6) accuracy in the heating rates in each cell. Consequently, this number of photons will influence not only the CPU time, but also the amount of communication between the processors/nodes. While pursuing decent accuracy on larger grids, the problem can be quickly dominated by passing photon buffers between processors and the associated MPI bottlenecks.
# Domain decomposition of radiative transfer might present its own problems. For example, if there are any radiation-driven fronts (I am thinking about ionization fronts in astrophysics, but coupling radiation to hydro might give rise to its own instabilities and fronts propagating at finite speeds), the order in which photons are passed between processors may become important. For example, the domain on the left may or may not have some important instability that will affect transfer in the domain on the right, on the timescale faster than the fluid flow. Then doing transfer in the domain on the right may be a waste of CPU time, until we have the solution from the domain on the left. Couple that with the fact that there is no left and right, but two angles (theta, phi) describing the direction of photon propagation, and you'll see how complex this problem can become.

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T17:09:54Z

Razoumov:

Project Title: '''Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres '''

Project originators:
*Howard Barker, Environment Canada
*Jacon Cole, Environment Canada
*Philip Austin, UBC

SHARCNET programming support:
*Pawel Pomorski
*Alex Razoumov

The goal of this project is to modify an existing radiative transfer code (one of the components of climate and weather modelling used by the EC group) to make it fully parallel. The code uses a Monte Carlo approach to inject photons into the domain studied and compute their propagation.

The approach of the initial code is to supply each processor with the entire spatial domain and inject N photons per each parallel processor. This approach does result in a parallel speedup but suffers from memory limitations. Thus the first improvement to the code will be to decompose the spatial domain into subdomains which will be assigned to individual processors. This will require adding code to handle photons transferring between domains as they cross the boundary.

Once that is done, the second stage of the project will be to improve the above approach to ensure good load balancing between processors.

==Safe physics assumptions==

# Radiation propagates at a finite speed "c", so strictly speaking the equation of radiative transfer should include a time-dependent advection term (differential transfer equation) or the "retarded" energy (integral transfer equation). The working (and pretty safe) assumption is that "c" is so large that all changes in the radiation field can be assumed instantaneous, and those "c"-dependent terms can be dropped.
# The conservation equations of radiation hydrodynamics describe conservation of mass, momentum, energy. Ideally, they should be solved in one (perhaps, implicit) update. Operator-splitting them into two steps (hydrodynamics and transfer) is good enough for this problem, but it's worth keeping in mind that it's an approximation.

==Approximations that we should worry about==

# It is assumed that all variations in matter properties caused by radiation -- heating and the resulting changes in opacity/emissivity -- are not fast, i.e. they happen on a fluid flow timescale (or shorter). Therefore, these changes can be computed in the hydrodynamical update. I suspect in the cloud problem many radiation-driven changes happen on a timescale dictated by microphysics of radiation-matter interaction that is often very short, e.g., a cloud can be heated or evaporated by radiation before it can adjust hydrodynamically. This means that one needs to do radiative transfer/microphysics updates continuously throughout the hydrodynamical timestep, as opposed to doing it once per timestep. There are two methods: doing subcycling (transfer-microphysics-transfer-microphysics-...), or doing a simultaneous implicit solve.
# With Monte Carlo transfer the stochastic error goes down as 1/sqrt(numberOfPhotons), in other words, shooting 1000 times more photons will only lower the errors by a factor of ~30. In order to have a solution that is accurate to 8-9 significant digits, how many photons one would need to propagate at each timestep, 1e20? This is why proper discretization of the transfer equation in all dimensions (3 spatial coordinates, two angles, frequency) is vastly superior to Monte Carlo for error control. There are many methods -- ray tracing, direct Boltzmann solver, and various approximations (variable Eddington tensors, moment-limited approximations) -- but they clearly go well beyond the scope of this programming project. As a sanity check with Monte Carlo, we should be aware of the solution accuracy, e.g. how many photons do we need to launch to have 1% (or 1e-4, 1e-6) accuracy in the heating rates in each cell. Consequently, this number of photons will influence not only the CPU time, but also the amount of communication between the processors/nodes. While pursuing decent accuracy on larger grids, the problem can be quickly dominated by passing photon buffers between processors and the associated MPI bottlenecks.
# Domain decomposition of radiative transfer might present its own problems. For example, if there are any radiation-driven fronts (I am thinking about ionization fronts in astrophysics, but coupling radiation to hydro might give rise to its own instabilities and fronts propagating at finite speeds), the order in which photons are passed between processors may become important. For example, the domain on the left may or may not have some important instability that will affect transfer in the domain on the right, on the timescale faster than the fluid flow. Then doing transfer in the domain on the right may be a waste of CPU time, until we have the solution from the domain on the left. Couple that with the fact that there is no left and right, but two angles (theta, phi) describing the direction of photon propagation, and you'll see how complex this problem can become.

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T17:09:14Z

Razoumov: /* Approximations that are not so clear */

Project Title: '''Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres '''

Project originators:
*Howard Barker, Environment Canada
*Jacon Cole, Environment Canada
*Philip Austin, UBC

SHARCNET programming support:
*Pawel Pomorski
*Alex Razoumov

The goal of this project is to modify an existing radiative transfer code (one of the components of climate and weather modelling used by the EC group) to make it fully parallel. The code uses a Monte Carlo approach to inject photons into the domain studied and compute their propagation.

The approach of the initial code is to supply each processor with the entire spatial domain and inject N photons per each parallel processor. This approach does result in a parallel speedup but suffers from memory limitations. Thus the first improvement to the code will be to decompose the spatial domain into subdomains which will be assigned to individual processors. This will require adding code to handle photons transferring between domains as they cross the boundary.

Once that is done, the second stage of the project will be to improve the above approach to ensure good load balancing between processors.

==Physics assumptions that we don't need to worry about==

# Radiation propagates at a finite speed "c", so strictly speaking the equation of radiative transfer should include a time-dependent advection term (differential transfer equation) or the "retarded" energy (integral transfer equation). The working (and pretty safe) assumption is that "c" is so large that all changes in the radiation field can be assumed instantaneous, and those "c"-dependent terms can be dropped.
# The conservation equations of radiation hydrodynamics describe conservation of mass, momentum, energy. Ideally, they should be solved in one (perhaps, implicit) update. Operator-splitting them into two steps (hydrodynamics and transfer) is good enough for this problem, but it's worth keeping in mind that it's an approximation.

==Approximations that are not so clear==

# It is assumed that all variations in matter properties caused by radiation -- heating and the resulting changes in opacity/emissivity -- are not fast, i.e. they happen on a fluid flow timescale (or shorter). Therefore, these changes can be computed in the hydrodynamical update. I suspect in the cloud problem many radiation-driven changes happen on a timescale dictated by microphysics of radiation-matter interaction that is often very short, e.g., a cloud can be heated or evaporated by radiation before it can adjust hydrodynamically. This means that one needs to do radiative transfer/microphysics updates continuously throughout the hydrodynamical timestep, as opposed to doing it once per timestep. There are two methods: doing subcycling (transfer-microphysics-transfer-microphysics-...), or doing a simultaneous implicit solve.
# With Monte Carlo transfer the stochastic error goes down as 1/sqrt(numberOfPhotons), in other words, shooting 1000 times more photons will only lower the errors by a factor of ~30. In order to have a solution that is accurate to 8-9 significant digits, how many photons one would need to propagate at each timestep, 1e20? This is why proper discretization of the transfer equation in all dimensions (3 spatial coordinates, two angles, frequency) is vastly superior to Monte Carlo for error control. There are many methods -- ray tracing, direct Boltzmann solver, and various approximations (variable Eddington tensors, moment-limited approximations) -- but they clearly go well beyond the scope of this programming project. As a sanity check with Monte Carlo, we should be aware of the solution accuracy, e.g. how many photons do we need to launch to have 1% (or 1e-4, 1e-6) accuracy in the heating rates in each cell. Consequently, this number of photons will influence not only the CPU time, but also the amount of communication between the processors/nodes. While pursuing decent accuracy on larger grids, the problem can be quickly dominated by passing photon buffers between processors and the associated MPI bottlenecks.
# Domain decomposition of radiative transfer might present its own problems. For example, if there are any radiation-driven fronts (I am thinking about ionization fronts in astrophysics, but coupling radiation to hydro might give rise to its own instabilities and fronts propagating at finite speeds), the order in which photons are passed between processors may become important. For example, the domain on the left may or may not have some important instability that will affect transfer in the domain on the right, on the timescale faster than the fluid flow. Then doing transfer in the domain on the right may be a waste of CPU time, until we have the solution from the domain on the left. Couple that with the fact that there is no left and right, but two angles (theta, phi) describing the direction of photon propagation, and you'll see how complex this problem can become.

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T16:49:28Z

Razoumov:

Project Title: '''Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres '''

Project originators:
*Howard Barker, Environment Canada
*Jacon Cole, Environment Canada
*Philip Austin, UBC

SHARCNET programming support:
*Pawel Pomorski
*Alex Razoumov

The goal of this project is to modify an existing radiative transfer code (one of the components of climate and weather modelling used by the EC group) to make it fully parallel. The code uses a Monte Carlo approach to inject photons into the domain studied and compute their propagation.

The approach of the initial code is to supply each processor with the entire spatial domain and inject N photons per each parallel processor. This approach does result in a parallel speedup but suffers from memory limitations. Thus the first improvement to the code will be to decompose the spatial domain into subdomains which will be assigned to individual processors. This will require adding code to handle photons transferring between domains as they cross the boundary.

Once that is done, the second stage of the project will be to improve the above approach to ensure good load balancing between processors.

==Physics assumptions that we don't need to worry about==

# Radiation propagates at a finite speed "c", so strictly speaking the equation of radiative transfer should include a time-dependent advection term (differential transfer equation) or the "retarded" energy (integral transfer equation). The working (and pretty safe) assumption is that "c" is so large that all changes in the radiation field can be assumed instantaneous, and those "c"-dependent terms can be dropped.
# The conservation equations of radiation hydrodynamics describe conservation of mass, momentum, energy. Ideally, they should be solved in one (perhaps, implicit) update. Operator-splitting them into two steps (hydrodynamics and transfer) is good enough for this problem, but it's worth keeping in mind that it's an approximation.

==Approximations that are not so clear==

# It is assumed that all variations in matter properties caused by radiation -- heating and the resulting changes in opacity/emissivity -- are not fast, i.e. they happen on a fluid flow timescale (or shorter). Therefore, these changes can be computed in the hydrodynamical update. I suspect in the cloud problem many radiation-driven changes happen on a timescale dictated by microphysics of radiation-matter interaction that is often very short, e.g., a cloud can be heated or evaporated by radiation before it can adjust hydrodynamically. This means that one needs to do radiative transfer/microphysics updates continuously throughout the hydrodynamical timestep, as opposed to doing it once per timestep. There are two methods: doing subcycling (transfer-microphysics-transfer-microphysics-...), or doing a simultaneous implicit solve.
# With Monte Carlo transfer the stochastic error goes down as 1/sqrt(numberOfPhotons), in other words, shooting 1000 times more photons will only lower the errors by a factor of ~30. In order to have a solution that is accurate to 8-9 significant digits, how many photons one would need to propagate at each timestep, 1e20? This is why proper discretization of the transfer equation in all dimensions (3 spatial coordinates, two angles, frequency) is vastly superior to Monte Carlo for error control. There are many methods -- ray tracing, direct Boltzmann solver, and various approximations (variable Eddington tensors, moment-limited approximations) -- but they clearly go well beyond the scope of this programming project. As a sanity check with Monte Carlo, we should be aware of the solution accuracy, e.g. how many photons do we need to launch to have 1% (or 1e-4, 1e-6) accuracy in the heating rates in each cell. Consequently, this number of photons will influence not only the CPU time, but also the amount of communication between the processors/nodes. While pursuing decent accuracy on larger grids, the problem can be quickly dominated by passing photon buffers from processor to processor and the associated MPI bottlenecks.

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T16:29:54Z

Razoumov:

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T16:03:34Z

Razoumov:

User:Ppomorsk/Toward Exascale Simulations of 3D Radiative Transfer for Cloudy Atmospheres

2010-10-12T16:01:26Z

Razoumov:

File:TestJobsRequin-numberCores.png

2010-09-13T17:57:31Z

Razoumov: distribution of test jobs on requin by number of cores

distribution of test jobs on requin by number of cores