SUMMARY OF DISCUSSION II
------------------------
(joint notes by Malte and Raymond)


00:45	0)	Next SC workshop

01:00	Shinji: There will be a 2nd SC meeting in 2015 in Oxford. The date is not
	yet decided but most probably at the end of march.


03:30	1)	When do we have a release ready of at least 2 PIC codes?

03:35	Jeff: pyOrbit is currently debugged by students and hopefully finished this summer.
04:00	James: We are currently using 2D+longitudinal solver for long bunches (=2.5D).
[After these rather direct responses to question 1) there was a discussion going on whether 
the various solvers are to be considered as 2D or 2.5D]
06:00	James: We are using a one dimensional projection of the density distribution for the
	longitudinal behaviour.
06:20	Jeff: 2.5D is only relevant if we want to include transverse impedances.
xx:xx	Simone: Ji would still need input to complete the benchmarking of IMPACT.
xx:xx	James: I could help with that, because I have the parameters and I understand the
	input of IMPACT.


07:30	 2)	Study: Validity test of PIC vs Frozen SC fully established. Alternatives?   

[We jumped from this question immediately to 8)]


18:40	 3)	What hardware and support is required for realistic simulations of our machine?

18:45	Frank: At the moment we lack the resources at CERN for excessive computations and are not in
	a comfortable situation.
18:55	James: This is in fact a good motivation for us to continue working on our GPU prototypes. We have
	alot of potential for people who need to do these simulations.
19:50	Ji: We should also attempt to not focus on a certain GPU and take care to make the code portable.
	Otherwise we work several years on the code, then the GPU will change and the work has to be done again. 		
	The GPU community uses mainly opencl for this reason, but most people use a coda lib for better performance.
	However this approach often makes the code not general enough to be used on other GPUs, which is
	a disadvantage.
xx:xx	Oliver: I agree, it is really time consuming. It's a huge effort and hence it has to be portable.
	We started a project at GSI in this regard but we abandoned it.
20:55	James: Indeed. We will probably have an update of new phi-cards which will introduce changes and
	then we have to see how these things are transferable.
xx:xx	Oliver: We should also include code performance parameters (how fast, how accurate...) in the
	benchmark.


23:00	 4)	Do we have the proper non-linear lattice models of our machines?
		Is our effort sufficient? Can we measure it?

23:05	Frank: With the PS and the PSB we are on our way towards a reliable non-linear model.


xx:xx	 5)	Which experiments should be envisaged for a full code vs. experiment benchmarking?

23:40	Ingo: It would be great if we have a full benchmarking. However this aproach often makes no sense,
	because we have to know and understand the crucial parameters in the physics. Often a benchmark
	is only meaningful when looking at a particular set of parameters. So we should
	look for a 'meaningful' benchmarking instead of a 'full code' benchmarking, by which I mean that
	the machines can be adjusted towards these observable parameters.
24:55	Frank: We want to propose three different experiments:
	1. The PS with the non-linear resonance
	2. Examining close to the half integer resonance at the PSB.
	3. The SPS
	We will try to prepare these experiments and make the data available for everyone.
[The audience had no obligations against these suggestions]
xx:xx	Simone: We are not shooting in the dark, since we are proposing something for which we already have
	measurements that we consider of good quality. We tested some simulation codes an they reproduced the effects
	up to a certain level and we have some theoretical understanding of the physics behind.
xx:xx	Frank: Additionally, these experiments have both coherent and incoherent effects and we can test both
	frozen and self-consistent codes.
28:05	Giuliano: This task can be quite delicate. For example in 2002 I began to reproduce the
	beam losses at the SIS18 GSI with Shinji, but I was unable to match the theoretical predictions well with the experiment.
xx:xx	Giuliano: It tooked us 2-3 months before we found an agreement. So before measuring the machines, we have to find
	something meaningful, interesting, new which we understand.
28:50	James: Beam losses is an important point, because it is the number one thing people are asking for.
	However I believe this is probably the least precise quantity we have when it comes to predictions.
29:22	Frank: Remember that in the PSB they are often loosing the entire beam and yet they are getting
	very close to the expectations from the simulations.
29:35	James: But in the case of tiny losses you see only the effects around the edge of the halo. And this
	is the part I am worried the most.
29:50	Simone: The idea we were had in mind was to start with something easy in the case of light losses. Say
	the first order of the taylor expansion. In the PSB we have around 80% of the beam lost whereas in the
	PS we can modulate these losses from 0% to 100%.
30:40	Shinji: It would be very good if we can change a few parameters to get a better understanding of the
	physics, for example the synchrotron frequency in the PS.
31:15	Simone: As a start we can make the data of the experiments available to the community. For example in
	the case of the PS the transverse profiles of the third order resonance, the loss marks and the longitudinal
	parameters as simple cases.

	And in July we will then have the machine back again and be able to tweak these parameters. We prepare
	these informations and put it on the web page.
33:30	Frank: We should also head for a deadline to finish this discussion before the march meeting.
[After this we talked about general impressions of the results we have learned at the meeting. goto 8) 34:00]


xx:xx	 6)	Is our theoretical understanding sufficient?


xx:xx	 7)	Requirements of SC codes (PIC/Frozen SC/Alternatives)
		-Fully operational and benchmarked lattice design tool (e.g. PTC, CHEF)
		-SC Benchmarking with the GSI benchmarking suite
		-Special Feature: time-varying fields, double RF, accelerations
		-Code benchmarking with experiments
		-Code availability including support for external modules
		-Speed and platform / Full release


08:00 	8)	Do we fully understand the noise and can we live with it, i.e. can we go to
		large number of turns with PIC codes?

08:15	Frank: We can not ignore noise, but hopefully we have a better understanding of noise after
	listening to the various talks. Is DELTA-F from the plasma community useful to 
	consider in modeling SC?
08:55	Ingo: DELTA-F is used by plasma physicists because their systems are so huge, but personally I
	doubt that this will be our choice in the forseeable future. What we have seen is that
	for XYZ (3D) and YZ (2D) solver the noise is different, and probably also in 2.5D models. I would
	like that we define some cases with a reasonable synchrotron period in order to make
	a benchmarking with the goal to keep the noise level low enough so that these trapping phenomena
	are not mitigated by noise.
	
	For this purpose Giuliano and other code authors can perhaps introduce some code-generated 
	noise level to determine what level of noise is tolerable or not. And then we try to 
	understand how our codes can handle it.
11:05	Frank: There is already that good sign Jim was showing today: It was the effect under certain
	parameter configurations that the emittance growth does not change anymore when adding 
	more particles. And once we are in this situation we can then compute over long-term
	simulations of around 1e5 turns.
12:10	Oliver: During the last SC meeting Jean-Luc presented an overview of using digital filters to
	get rid of the noise. We should consider looking into this.
12:35	Giuliano: There was already an attempt to introduce artificial noise in a frozen SC model
	done by Shangajew (IPAC13 ???) 2014 to determine the effect of noise during resonance crossing.
13:10	Oliver: But this is just white noise he added. I have the feeling that the noise in our PIC codes
	is of completely different nature.
13:25	Giuliano: The point is that the noise is of destructive nature and this was just a first attempt
	to look at its effect during resonance crossing. I think that one should first study the effect
	of the noise on the non-linear dynamics.
13:38	Oliver: But you do not have the Struckmeier-effect with this method. You always have emittance
	growth, however Juergen showed that the noise in the PIC code does not necessarily lead to 
	emittance growth and is of self-consistent nature.
15:00	Giuliano: From the results of this model (white noise) we can see the dependency of this noise
	on the number of turns. Of course it is not the noise you (Oliver) were mentioning, but it is at least
	a start in approaching the problem.
16:10	Ji: We also have interbeam scattering. I would say that the noise we see in the PIC codes may
	not be completely useless. We should compare the effects of interbeam scattering and this
	artificial noise. A better understanding of both effects can lead to an automatically inclusion
	of interbeam scattering into the PIC simulations.
17:05	Ingo: Again: We should find a strategy to compare trapping with code quality and define a case for
 	benchmarks. Perhaps a group of people interested in that should meet to define a good physics
	quality for trapping.
18:10	Simone: In this case we should choose a 1D resonance and not a 2D one.
34:00	Ji: We should also ask ourselves of the effects of errors. Are errors really the same as the noise we
	observe? Errors coming, for example, from large gridding induced emittance growth, while noise does not
	necessarily. And in what way are its effects different from those of the interbeam collisions?
35:50	Giuliano: That is indeed something which is not 100% clear.
36:30	Ingo: This depends on the problem we are studying. We are mostly interested in resonance effects
	in our machines. We should identify all sources which have the potential to break down Hamiltonian 
	mechanics, since we are studying effects (noise) which invalidate Hamiltonian mechanics.
37:35	Ji: Using for example a 2nd- or a 4th order symplectic integrator you will have errors, but we accept
	these errors as long as everything is symplectic. But on the other hand you have these emittance growth
	from noise or the miracle collision effects which actually shows a much larger growth than expected.
xx:xx	Vincenzo: Can we see the islands on the wire-scanner?
xx:xx	Simone: On the wire-scanners you can recognize the boundaries. You can also reconstruct the phase space
	from the turn-by-turn data (for example MTE in the PS).


xx:xx	 9) 	How well can we reproduce the experiments with codes, in particular for the
		PSB & PS?

[see 5)]