Quick viewing(Text Mode)

Introduction to OSIRIS 4.0 for Developers (And Users)

Introduction to OSIRIS 4.0 for Developers (And Users)

Introduction to OSIRIS 4.0 for developers (and users)

1,2 . A. Fonseca

1 GoLP/IPFN, Instituto Superior Técnico, Lisboa, Portugal 2 DCTI, ISCTE-Instituto Universitário de Lisboa, Portugal

Ricardo Fonseca | OSIRIS Workshop 2017 The work of many people IST – J. L. Martins, T. Grismayer, J. Vieira, F. Gaudio, G. Inchingolo , P. Ratinho, K. golp Schoefer, M. Vranic, U. Sinha, T. Mehrling, A. Helm, L. O. Silva grupgrupoo de lasers e plasmas UCLA – A. Tableman, A. Davidson, J. May, K. Miller, H. Wen, P. Yu, T. Dalichaouch, F. Tsung, V.K.Decyk, W. An, X. Xu, W. B. Mori

2 Ricardo Fonseca | OSIRIS Workshop 2017 osiris 3.0

osiris framework · Massivelly Parallel, Fully Relativistic Particle-in-Cell (PIC) Code Osiris · Visualization and Data Analysis Infrastructure 3.0 · Developed by the osiris.consortium ⇒ UCLA + IST

code features · Scalability to ~ 1.6 M cores · SIMD hardware optimized · Parallel I/O · Dynamic Load Balancing Ricardo Fonseca: [email protected] · QED module Frank Tsung: [email protected] · Particle merging GPGPU support http://epp.tecnico.ulisboa.pt/ · · Xeon Phi support http://plasmasim.physics.ucla.edu/ 3 Ricardo Fonseca | OSIRIS Workshop 2017 Outline

• The OSIRIS Particle-In-Cell infrastructure – Overview of the OSIRIS framework – The need for a new structure • Moving into 4.0 – Main goals – New language features/techniques available – New file structure and features • Developing a new simulation mode – The new simulation class – Adding new features to the code • Managing the code – Flash introduction to our GitHub repository • Overview

4 Ricardo Fonseca | OSIRIS Workshop 2017 The OSIRIS particle-in-cell framework

UNIVAC 1 - 1951 Internal view The OSIRIS framework

• Fully Relativistic, Electromagnetic Particle-In-Cell Code PIC algorithm – Massively Parallel

du q ⎛ 1 ⎞ – Dynamic Load Balancing = E + u × B dt m ⎝⎜ γ ⎠⎟ – High-order particle interpolation – Multiple field solvers / particle pushers Integration of equations of motion, moving particles – Particle merging

Fi → ui → xi – Advanced Hardware Support • Extended Diagnostic Capabilities

Weighting Weighting – Griding of arbitrary particle quantities Δt ( E , B )j → Fi (x,u)j → Jj – Spatial / Temporal averaging of grid quantities – Particle Selection / Tracking

Integration of Field – Tight integration with visXD Equations on the grid • Additional Simulation Modes / Physics models Jj →( E , B )j – ADK tunnel / impact ionization ∂E ! – Binary collisions = c∇ × B − 4π j ∂t – High-density hybrid ∂B ! = −c∇ × E – Radiation Cooling | QED module ∂t – Ponderomotive guiding center Osir3.0is – Quasi-3D geometry

6 Ricardo Fonseca | OSIRIS Workshop 2017 OSIRIS source tree

Implementation

m_math • Written in 9x | 2003 and C os-math.f90 stringutil os-stringutil.f90

m_time • Parallelization using MPI/OpenMP os-time.f90

m_qed m_cross m_utilities m_photons_class os-qed.f03 os-util.f90 os-photons.f03 os-cross.f90 m_species_collisions • Explicit SSE / AVX / QPX / Xeon m_antenna os-spec-collisions.f03 os-antenna.f90 Phi / CUDA support m_species_boundary os-spec-boundary.f03 m_antenna_array m_species_comm m_mergedel os-antenna_array.f90 os-spec-comm.f90 os-mergedel.f03

• SVN → Git(Hub) m_species_tracks os-spec-tracks.f03 m_species_utilities m_space m_species_qed_define os-spec-util.f03 m_species_memory os-space.f90 os-spec-qed-define.f03 os-spec-memory.f90 m_species_current m_cathode m_vdf_smooth • Continuous integration / unit os-spec-current.f03 os-vdf-smooth.f90 os-cathode.f03

m_species_phasespace testing / test benchmarks os-spec-phasespace.f03 m_species_charge os-spec-charge.f90 m_restart m_file_system m_piston os-restart.f90 os-files.f90 os-spec-piston.f90 hdf5_util m_species_diagnostics m_diagnostic_utilities os-dutil-hdf5.f90 m_particles_define os-spec-diagnostics.f03 m_species_udist m_species_v3dep os-dutil.f90 os-particles-define.f03 m_species os-spec-udist.f03 os-spec-v3dep.f90 m_grid os-species.f03 m_time_avg os-grid.f90 m_species_v3int m_species_define os-timeavg.f90 m_species_loadbalance os-spec-v3int.f90 os-spec-define.f03 os-spec-loadbalance.f90 m_wall os-wall.f90 m_vdf_report m_system os-vdf-report.f90 os-sys-multi.f90 m_vdf_reportfile m_neutral m_fparser m_vdf_average os-vdf-reportfile.f90 m_node_conf m_species_initfields m_species_profile os-neutral.f03 os-fparser.f90 os-vdf-average.f90 os-nconf.f90 os-spec-initfields.f90 os-spec-profile.f90 m_species_rawdiag os-spec-rawdiag.f03 m_particles_qed os-particles-qed.f03 m_parameters m_diag_neutral m_emf_es_solver os-param.f90 m_zpulse os-dneutral.f90 os-emf-es-solver.f03 os-zpulse.f90

m_neutral_pgc m_current_diag os-neutral-pgc.f03 m_vdf os-current-diagnostics.f90 os-vdf.f90 m_vpml m_grid_define os-emf-vpml.f03 os-grid-define.f90 m_emf_gridval os-emf-gridval.f90 m_random_cmwc m_particles m_current os-random-cmwc.f03 m_random_class os-particles.f03 os-current.f90 m_random_mwc os-random-class.f03 os-random-mwc.f03 m_species_qed m_emf_define m_current_define m_emf_gridcenter m_vdf_memory os-spec-qed.f03 os-emf-define.f03 os-current-define.f90 m_random_kiss os-emf-gridcenter.f90 os-vdf-memory.f90 os-random-kiss.f03 m_logprof m_species_vpush m_lindman m_random_hash os-logprof.f90 m_wall_define m_simulation_qed os-spec-vpush.f03 os-emf-lindman.f90 os-random-hash.f03 os-wall-define.f90 os-simulation-qed.f03 m_wall_comm m_random_mt os-wall-comm.f90 os-random-mt.f03 m_species_accelerate m_emf_bound m_emf m_emf_solver m_random_r250 os-spec-accel.f90 os-emf-boundary.f90 m_emf_psi os-emf.f03 os-emf-solver.f03 os-random-r250.f03 os-emf-psi.f90 m_emf_diag m_vdf_interpolate os-emf-diagnostics.f03 os-vdf-interpolate.f90

m_random OSIRIS in numbers os-random.f03

m_emf_marder m_vdf_comm os-emf-marder.f90 m_particles_pgc os-vdf-comm.f90 • Start year: 1998 os-particles-pgc.f03 m_emf_poynting m_species_radcool m_vdf_math os-emf-poynting.f90 m_emf_pmc os-spec-radcool.f90 os-vdf-math.f90 m_species_pgc os-emf-pmc.f90 os-spec-pgc.f03 m_species_push m_emf_pec os-spec-push.f03 os-emf-pec.f90 • 4480852 characters m_emf_interpolate os-emf-interpolate.f03 m_vdf_define os-vdf-define.f90 m_dynamic_loadbalance m_simulation osiris os-dynloadbalance.f03 os-simulation.f03 os-main.f03 m_units m_time_step m_simulation_pgc os-units.f90 os-tstep.f90 os-simulation-pgc.f03 • 143310 lines m_emf_pgc os-emf-pgc.f03 m_pgc_deposite os-pgc-deposite.f03 m_particles_charge – 118289 (Fortran 95|03) m_pgc_interpolate os-particles-charge.f90 os-pgc-interpolate.f03 m_grid_memory m_grid_parallel os-grid-memory.f90 – 19249 (C) os-grid-parallel.f90 m_emf_ncifilter m_grid_report os-emf-ncifilter.f90 os-grid-report.f90 • 187 source files

7 Ricardo Fonseca | OSIRIS Workshop 2017 Old OSIRIS object structure

OSIRIS object structure

Physical Classes

EM Field Current Particles

EM Current Boundary Boundary Species Particles Diagnostics EM Current Diagnostics Smooth

Current Diagnostics Species Profile

Species Boundary

Species Diagnostics

Diagnostic Utilities VDF Domain Decomposition

System Support Classes •

8 Ricardo Fonseca | OSIRIS Workshop 2017 OO concepts implemented in Fortran95

• No real inheritance • Difcult to maintain and expand – Use derived types – Changes in one module afects all code – Include superclass as structure member – Some options only available at compile time • No function pointers / virtual methods subroutine push_species( this, emf, jay, … )

– Run-time options selected through conditional type( t_species ), intent(inout) :: this statements ! (…) select case ( this%push_type ) case ( p_std ) type t_photons call advance_deposit( this, emf, jay, … )

! parent class case ( p_pgc ) type( t_species ) :: t_species call advance_deposit_emf_pgc( this, emf, jay, … ) (…) case ( p_qed ) ! number of pairs created call advance_deposit_qed( this, emf, jay, … ) integer :: num_pairs = 0 (…) ! (…) end type t_photons end select (…) ! (…) subroutine update_boundary_phot( this, no_co, dt ) end subroutine push_species type( t_photons ), intent(inout) :: this (…) subroutine advance_emf( this, jay, … )

! Call superclass method type( t_emf ), intent( inout ) :: this call update_boundary( this%t_species, no_co, dt ) ! (…) ! Do additional work if needed if ( this%use_pgc ) then (…) call advance_pgc( this , dt , coordinates , no_co ) endif end subroutine update_boundary_phot end subroutine advance_emf 9 Ricardo Fonseca | OSIRIS Workshop 2017 Why move to a new code structure?

• Main issue - Adding new features – This generally meant changing the main code and critical routines – At best these changes made the code more complicated – At worst they impacted on the performance of the normal simulation modes and could cause it to crash

• Additional issues – A growing portion of the source code is now written in C, and Fortran C interoperability had to be done by ourselves, and updated for each new /system – Some routines are very similar and would benefit from template based code generation – Flat file hierarchy was becoming difcult to manage

10 Ricardo Fonseca | OSIRIS Workshop 2017 Moving into 4.0

Laser Wakefield Acceleration 3D Simulation using the OSIRIS code Main goals

• Allow for the development of new features with minimal impact to the rest of the code – Only change 1 file in the main code structures – New features are encapsulated inside a separate folder – Easy to remove from code, encouraging new developers and simplifying maintenance

• Modernize code structure by taking advantage of new language features – Clean up base code structure removing references to other sim. modes – Improve interface with C code – Replace similar routines with template based programming

12 Ricardo Fonseca | OSIRIS Workshop 2017 Fortran 2003

Features highlight • Simplify code structure • Object-oriented support • All object oriented concepts can now be – Type extension and inheritance expressed in a more natural way – Polymorphism • Separate diferent simulation modes into – Dynamic type allocation diferent object – Type-bound procedures (methods) • Improve selection of runtime options • Procedure pointers • No need for conditional code execution

• Standardized interoperability with C • Simplify Fortran-C interface

• Enhanced Integration with the host operating system • Easier interface to SIMD hardware accelerated code

• There is finally (2016) a widespread support of most of these features • Remove most of POSIX interface module • Improve portability

Fortran 2003 Standard, final draft (ISO/IEC 1539-1:2004(E)) 13 Ricardo Fonseca | OSIRIS Workshop 2017 Compiler Support for Fortran 2003

• Using only a subset of F2003 features OSIRIS F2003 Compiler – Lowest common denominator approach support GNU gfortran 5.x full • Only 1 feature missing in some – Using type bound procedures that are not defined in GNU gfortran 6.x full the same module as the class definition (through the use of explicit interfaces) Intel ifort 2016, 2017, 2018 full

Intel ifort 2015 incomplete • Workaround for compilers missing this feature – Defining type bound procedures in the same module Intel ifort 2013sp1 incomplete as the class definition that just call the routines defined in other files PGI pgfortran 15.10 incomplete – Done through a macro at compile time

IBM xlf2003 14.1 BG/Q full • With this workaround all compilers listed successfully compiled and ran the code Although the F2003 standard has been around for a while, many compilers don't fully support it

14 Ricardo Fonseca | OSIRIS Workshop 2017 Template based code generation

• Fortran 2003 does not fully support template based code template.f03 generation

– Does support parameterized derived types function FNAME(x) PTYPE :: x, FNAME • Some routines are very similar FNAME = x*x*x end function FNAME – Writing / maintaining all versions is error prone – Using code templates greatly simplifies code and minimizes errors

• Can be implemented using a preprocessor generator.f03 – C preprocessor can be applied to Fortran files before

calling the Fortran compiler #define FNAME cube_real #define PTYPE real – Most Fortran compilers are compatible with C #include “template.f03” preprocessor output #define FNAME cube_cmplx • Others need preprocessor output to be sanitized #define PTYPE complex before compilation #include “template.f03” • Repeat for each variant #define FNAME cube_dbl #define PTYPE double precision • Define new function name #include “template.f03” • Define template parameters • Include template code 15 Ricardo Fonseca | OSIRIS Workshop 2017 Example: Charge deposition

template.f03 Generate versions for interpolation levels 1 to 4 subroutine DEPOSIT_RHO_2D( rho, ix, x, q, np )

implicit none deposit.f03 type( t_vdf ), intent(inout) :: rho integer, dimension(:,:), intent(in) :: ix ! Linear interpolation real(p_k_part), dimension(:,:), intent(in) :: x #define DEPOSIT_RHO_2D deposit_rho_2d_s1 real(p_k_part), dimension( : ), intent(in) :: q #define SPLINE spline_s1 integer, intent(in) :: np #define LP 0 #define UP 1 ! local variables #include “template.f03” integer :: l, i1, i2, k1, k2 real(p_k_fld) :: dx1, dx2, lq ! Quadratic interpolation real(p_k_fld), dimension(LP:UP) :: w1, w2 #define DEPOSIT_RHO_2D deposit_rho_2d_s2 #define SPLINE spline_s2 do l = 1, np #define LP -1 #define UP 1 i1 = ix(1,l) #include “template.f03” i2 = ix(2,l) dx1 = real( x(1,l), p_k_fld ) ! Cubic interpolation dx2 = real( x(2,l), p_k_fld ) #define DEPOSIT_RHO_2D deposit_rho_2d_s3 lq = real( q(l) , p_k_fld ) #define SPLINE spline_s3 #define LP -1 ! get spline weitghts for x and y #define UP 2 call SPLINE( dx1, w1 ) #include “template.f03” call SPLINE( dx2, w2 )

! Quartic interpolation ! Deposit Charge #define DEPOSIT_RHO_2D deposit_rho_2d_s4 do k2 = LP, UP #define SPLINE spline_s4 do k1 = LP, UP #define LP -2 rho%f2(1,i1 + k1,i2 + k2) = rho%f2(1,i1 + k1,i2 + k2) + & #define UP 2 lq * w1(k1)* w2(k2) #include “template.f03” enddo enddo

enddo

end subroutine DEPOSIT_RHO_2D 16 Ricardo Fonseca | OSIRIS Workshop 2017 New source tree structure

• OSIRIS 3.x used a flat source tree

– 145 files in the “source” folder Organized by folders – Single Makefile • Files related to the same class are together

• OSIRIS 4.x implements an actual source tree – Use 1 folder for every class / group Separate Makefiles • Each folder has its own – Each folder has its own Makefile Makefile – Nested folders are possible – Migration from 3.x structure not yet completed

– Limitation: source file names must be diferent, even if they reside in diferent Current stats directories • 17 folders • 224 files

• Avoid adding files to the source root – Major features should create a new directory

17 Ricardo Fonseca | OSIRIS Workshop 2017 New random number generator module

• Multiple (pseudo) random number generation algorithms osiris input file • Mersenne-Twister (default) ! Global options • R250 simulation { • Marsaglia MWC (multiply with carry) random_algorithm = “r250”, • Marsaglia CMCW (complimentary multiply with random_seed = 9262, carry) } • Hashing RNG (from Numerical Recipes) • Marsaglia KISS ! use local RNG • Can be selected in the input file class(t_random_hash) :: local_rng • Re-run simulations with diferent RNG/seed call local_rng % init_genrand_scalar( seed ) • Available as an object for developers dice = local_rng % genrand_res53() • Devs. can use multiple separate RNGs instead of global RNG 18 Ricardo Fonseca | OSIRIS Workshop 2017 Input file structure remains mainly the same

simulation { algorithm = "pgc", ! Use the Ponderomotive Guiding center • The global structure remains unaltered }

• The initial simulation section has added node_conf { node_number(1:2) = 2, 2, ! this is a 4 node run relevance if_periodic(1:2) = .true., .true., ! using periodic boundaries

n_threads = 2, ! and 2 threads per node • algorithm parameter defines the type of ! (so it should use 8 cores total) } simulation !------spatial grid------grid { nx_p(1:2) = 128, 128, } ! we use a 128 x 128 grid

!------time step and global data dump timestep number------• Diferent simulation modes may change structure time_step { • Remove existing sections dt = 0.07, ! the time step will be 0.07 ndump = 1, ! and the global dumps are set for every ! iteration • Add new ones }

!------spatial limits of the simulations------• Change allowed parameters space { xmin(1:2) = -6.4 , -6.4, ! setup a 12.8 x 12.8 global simulation ! space xmax(1:2) = 6.4 , 6.4, ! no moving window specified } • Some sections have changed !------time limits ------time • Check documentation { tmin = 0.0, tmax = 70.0, ! run up to t = 70.0 • Only minor changes required to most existing } el_mag_fld input files { solver = "yee", ! default (…)

19 Ricardo Fonseca | OSIRIS Workshop 2017 Developing a new simulation mode

NIVIDIA Fermi K20x die OSIRIS 4.0 t_simulation class

type :: t_simulation

type( t_node_conf ) :: no_co • All simulation objects are contained in a global type( t_grid ) :: grid t_simulation object type( t_time_step ) :: tstep type( t_restart ) :: restart • This class defines general data structures and type( t_options ) :: options methods for a simulation type( t_space ) :: g_space type( t_time ) :: time • All of these can be overridden by subclasses that type( t_zpulse_list ) :: zpulse_list implement diferent simulation modes type( t_antenna_array ) :: antenna_array class( t_current ), pointer :: jay => null() • Includes both physical and support classes class( t_emf ), pointer :: emf => null() class( t_particles ), pointer :: part => null()

contains • Implements the standard EM-PIC algorithm procedure :: iter => iter_sim • also considered making it a virtual base class procedure :: allocate_objs => allocate_objs_sim procedure :: init => init_sim procedure :: cleanup => cleanup_sim • Design goals procedure :: read_input => read_input_sim

procedure :: write_checkpoint => write_checkpoint_sim • Keep most of existing code-base procedure :: list_algorithm => list_algorithm_sim • Allow easy extension and encapsulation of code procedure :: test_input => test_input_sim end type t_simulation

21 Ricardo Fonseca | OSIRIS Workshop 2017 t_simulation methods

Method Functionality

Implements PIC algorithm iteration: particle/field advance, boundary conditions iter (including parallel comms.), diagnostics

allocate_objs Allocates required member objects: jay, emf, particles

init Initialization code (includes initializing from checkpoint)

cleanup House cleaning

read_input Reads in the input file

write_checkpoint Writes checkpoint information

list_algorithm Lists algorithm details

test_input Tests simulation parameters for validity (Courant condition / parallel partition

All of these methods can be overridden

22 Ricardo Fonseca | OSIRIS Workshop 2017 Executing the main program

os-main.f03 1 call timer_init() Initialize timers 2 call init_options( opts ) Initialize runtime options and store wall clock time 3 call system_init( opts ) Initialize system code (this also initializes MPI) 4 call init_mem() Initialize dynamic memory system 5 call print_init_banner() Print Initialization banner 6 call initialize( opts, sim ) Read input file and setup simulation structure 7 if ( root(sim%no_co) ) then 8 call sim%list_algorithm() Print main algorithm parameters 9 endif 10 call status_mem( comm( sim%no_co ) ) Print dynamic memory status 11 call run_sim( sim ) Run simulation 12 call list_total_event_times( n(sim%tstep), comm(sim%no_co), label = 'final' ) Write detailed timing information to disk 13 call sim%cleanup( ) Cleanup and shut down 14 deallocate( sim ) 15 if ( mpi_node() == 0 ) then Print final message 16 print *, 'Osiris run completed normally' 17 endif 18 call finalize_mem() Finalize dynamic memory system 19 call system_cleanup() this calls mpi_finalize

23 Ricardo Fonseca | OSIRIS Workshop 2017 Creating a new simulation mode

• Create a subclass of t_simulation type, extends( t_simulation ) :: t_simulation_new – Add additional member variables (if needed) integer :: extra – Add additional methods (if needed) contains procedure :: allocate_objs => allocate_objs_new – Override existing methods (if needed) end type t_simulation_new – In particular allocate_objs() will generally need to be overridden • Allows for the allocation of diferent types of emf, subroutine allocate_objs_new( sim ) jay or particles objects use m_particles_new implicit none • Modify os-main.f03 class( t_simulation_new ), intent(inout) :: sim – Add use statement for new module – Modify read_sim_options() to recognize new input file SCR_ROOT('Allocating NEW particle objects.') option allocate( t_particles_new :: sim%part ) – Modify initialize() routine to allocate simulation objects of the new class ! allocate any remaining objects in superclass call sim % t_simulation % allocate_objs() • Modify Makefile – Include the Makefile for the new simulation mode end subroutine allocate_objs_new • Remember to put all new code in a separate folder

24 Ricardo Fonseca | OSIRIS Workshop 2017 Run-time selection of simulation mode

new osiris input file • Initial section of input file sets simulation mode ! Global options simulation • Initialization code reads this first { algorithm = “new", • Then calls initialize() routine } – Allocates simulation object of corresponding class node_conf – For this object { node_number(1:2) = 1,1, • Calls the allocate_objs() method ! (…) • Calls the read_input() method

initialize(opts,sim) : os-main.f03 • Calls the init() method ! Read global options – Returns to the main program to start simulation call read_sim_options( opts, input_file )

! Allocate simulation object based on algorithm select case ( opts%algorithm ) • Any/all of these methods may be overridden from the case( p_standard ) ! Standard EM-PIC simulation base t_simulation class allocate( t_simulation :: sim ) – In most scenarios only the allocate_objs() needs to be case( p_sim_new ) overridden ! New type of simulation allocate( t_simulation_new :: sim ) – Actual diferences occur only in member objects end select 25 Ricardo Fonseca | OSIRIS Workshop 2017 Example: new particles

• New simulation mode particles section accepts diferent parameters type, extends( t_particles ) :: t_particles_new • Override allocate_objs() method in contains ! Allocate species_new objects instead t_simulation_new to allocate objects of this new procedure :: allocate_objs => allocate_objs_part_new type procedure :: read_input => read_input_new end type t_particles_new • The developer only needs to implement: • allocate_objs_part_new() - allocate a diferent species class, species_new subroutine read_input_new( this, input_file, periodic, & • read_input_new() - implement new particles if_move, grid, dt, & section on input file sim_options, ndump_global )

! new parameters • No changes required to other routines ! … • The default read_input() method of the sim read (input_file%nml_text, nml = nl_particles, iostat = ierr) object will call the read_input() method of the end subroutine read_input_new part object

26 Ricardo Fonseca | OSIRIS Workshop 2017 Example: new species pusher

• New simulation mode includes species with a diferent pusher type, extends( t_species ) :: t_species_new • Override allocate_objs() method in ! no additional class members, just a diferent pusher t_particles_new to allocate objects of this new contains procedure :: push => push_species_new type procedure :: list_algorithm => list_algorithm_spec_new end type t_species_new • The developer only needs to implement: • push_species_new() - the diferent pusher subroutine list_algorithm_spec_new( this ) • list_algorithm_spec_new() - print information about the new pusher implicit none class( t_species_new ), intent(in) :: this

• No changes required to other routines print *, ' ' • The default iter() routine will call the print *, trim(this%name),' :' print *, '- Type NEW pusher' advance_deposit() method of the part object • Which will then call the push() method for all end subroutine list_algorithm_spec_new species objects

27 Ricardo Fonseca | OSIRIS Workshop 2017 Managing the code

Intel Xeon Phi 5110p die OSIRIS 4.0 is now hosted on GitHub

https://github.com/GoLP-IST/osiris

29 Ricardo Fonseca | OSIRIS Workshop 2017 Please visit the wiki!

https://github.com/GoLP-IST/osiris/wiki

30 Ricardo Fonseca | OSIRIS Workshop 2017 Overview

Harvard Mark I - 1944 Rear view of Section Overview

• The OSIRIS particle-in-cell framework • State-of-the-art relativistic EM-PIC algorithm • Massively Parallel for large scale simulations / efcient enough to run on laptops • Widely used in many kinetic plasma scenarios, from high- intensity laser plasma interaction to astrophysical shocks

• OSIRIS 4.0 is a robust, extensible framework • Fully object oriented using Fortran 2003 • Supports many additional simulation modes and physical models • Can be safely and efciently extended to include new features

• Move to 4.0 now! • The 4.x series is ready for production use • All new development must go into this version Osiris • Go check out the GitHub repository and start using it today! 4.0

32 Ricardo Fonseca | OSIRIS Workshop 2017