Prolongation/Notes - Revision history

Hinder: /* 2017-08-18: Transition zone */

2017-08-18T17:30:55Z

‎2017-08-18: Transition zone

Hinder: /* 2017-08-09: Schedule */

2017-08-17T16:02:49Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-14T22:39:52Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-14T22:39:10Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-14T22:38:57Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-14T22:26:11Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-11T22:23:23Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-09T19:12:04Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-09T18:44:02Z

‎2017-08-09: Schedule

Hinder: /* 2017-08-09: Schedule */

2017-08-09T18:41:58Z

‎2017-08-09: Schedule

←Older revision		Revision as of 17:30, 18 August 2017
Line 118:		Line 118:

	* When we prolongate the ks, we could also prolongate the state vector. However, this is going to be used by MoL in its integration, so we would lose information. We could copy the state vector into a temporary variable (e.g. the scratch space), then prolongate it, then swap it out with the scratch space. so now we would have y_n from the coarse grid in the scratch space. We will then need access to this at the end of the step, so probably we just use another grid function for it. Then we may as well use that instead of the scratch space. So we define a new gridfunction for the coarse y_n, and use it to store the prolongated evolved variables. This will be kept around for the whole step, and used at the end to compute y_{n+1} on the coarse grid, and hence to do the blending.		* When we prolongate the ks, we could also prolongate the state vector. However, this is going to be used by MoL in its integration, so we would lose information. We could copy the state vector into a temporary variable (e.g. the scratch space), then prolongate it, then swap it out with the scratch space. so now we would have y_n from the coarse grid in the scratch space. We will then need access to this at the end of the step, so probably we just use another grid function for it. Then we may as well use that instead of the scratch space. So we define a new gridfunction for the coarse y_n, and use it to store the prolongated evolved variables. This will be kept around for the whole step, and used at the end to compute y_{n+1} on the coarse grid, and hence to do the blending.
		+
		+	* It seems like applying the blending at every substep would be better. Assume that you have the solution on the coarse grid for the current step. This will result in a certain error wrt the continuum solution. When you take the first substep on the fine grid, you will get a smaller error, in a way which is not smoothly related to the coarse grid error. The last evolved point will "see" the coarse grid solution from the prolongated points as a boundary condition, and the evaluation of the derivatives using this point will effectively be differencing a discontinuous "solution". We don't apply the blending until the end of the fine grid step, so any effects of this problem will propagate into the domain into a region of size nghosts*4 (more or less). After the 4 substeps, we then blend the coarse grid solution with the fine grid in the transition zone. So I can imagine that this helps a bit, but it doesn't seem to solve the problem in the best way.
		+
		+	* Instead, we could compute the ks in the transition zone as a blending between the ks that we prolongate with, and the ks that come from evolution on the fine grid. I think this would smooth out the discontinuity between the grids much better.
		+
		+	* How is this related to the "sponge" boundary conditions that Bishop mentioned?

	===Plan===		===Plan===

←Older revision		Revision as of 16:02, 17 August 2017
Line 108:		Line 108:
	\|-		\|-
	\|}		\|}
		+
		+	==2017-08-18: Transition zone==
		+
		+	* Need to prolongate an additional set of points (number should be a parameter; will try 3 to start with).
		+
		+	* Can implement this using the existing code for buffer zones. Should be able to set "use_buffer_zones = yes" and "additional_buffer_zones = -nghosts*(rk_substeps-2). This will remove all but the last nghosts buffer zones.
		+
		+	* Now, when Carpet prolongates the ks, it will give us all 6 points. However, now there is a problem. We need to continue to do our RK prolongation in MoL on the last three points. No code change needed. But then we need to identify the transition zone. This is the set of buffer points which are NOT the last three ghost points. For now, we can assume that all internal boundary faces are refinement boundaries, and run on a single process so there are no interprocessor boundaries.
		+
		+	* When we prolongate the ks, we could also prolongate the state vector. However, this is going to be used by MoL in its integration, so we would lose information. We could copy the state vector into a temporary variable (e.g. the scratch space), then prolongate it, then swap it out with the scratch space. so now we would have y_n from the coarse grid in the scratch space. We will then need access to this at the end of the step, so probably we just use another grid function for it. Then we may as well use that instead of the scratch space. So we define a new gridfunction for the coarse y_n, and use it to store the prolongated evolved variables. This will be kept around for the whole step, and used at the end to compute y_{n+1} on the coarse grid, and hence to do the blending.
		+
		+	===Plan===
		+
		+	* Add three buffer zones to the simulation
		+	* Add a new gridfunction for the prolongated state vector
		+	* Prolongate the state vector at the same time as the ks and store the result in the prolongated state vector variable (do this by a store-and-swap strategy)
		+	* At the end of the time step, compute pointwise the coarse grid y_{n+1} from the ks and the prolongated y_n, and blend it with the integrated fine grid solution on the transition zone

@@ Line 63: / Line 63: @@
 |'''When'''
 |'''Old'''
-|'''New'''
+|'''Changes for RK prolongation'''
 |-
 |CCTK_INITIAL

@@ Line 70: / Line 70: @@
 |-
 |CCTK_EVOL
-|Time and iteration variables advanced. Time and iteration variables advanced
+|Time and iteration variables advanced.
+|
 |-

@@ Line 71: / Line 71: @@
 |CCTK_EVOL
 |Time and iteration variables advanced. Time and iteration variables advanced
+|
 |-
 |MoL_ProlongateKs
+|
-|Prolongate ks into RBs.  Copy ks into kTildes on the RBs, poison kTildes elsewhere.
+|Prolongate ks into RBs.  Copy ks into kTildes everywhere (in future, only on the RBs).
 |-
 |Loop over steps:
@@ Line 85: / Line 89: @@
 |-
 | MoL_RHSBoundaries
-| Set boundaries of RHSs (ML_BSSN uses CalcRHS instead)
-| Compute RHS in RB using kTildes (saved prolongated coarse grid ks)
+| Compute RHS in RB using kTildes (currently also compute in ghost zones)
 |-
-|MoL_StoreKs
+|MoL_SetKs
+|
-|Compute and store the current level k variables from the RHS variables into the ks over the whole grid.  Apply BCs for the outer boundaries of the ks?
+|Compute and store the k variables from the RHS variables into the ks over the whole grid.  Apply BCs for the interprocessor and outer boundaries of the ks. Prolongation is still disabled.
 |-
 | MoL_Add
@@ Line 96: / Line 100: @@
 |-
 | MoL_PostStep
-| Sync state vector ghost zones, prolongate state vector refinement boundaries, apply physical BCs
+| Sync evolved variable ghost zones, apply BCs.  Prolongate RBs of evolved variables.
-| ''Don't'' prolongate state vector, probably only sync on apply BCs.  On last step, update state vector in RB using RK (might move this to another time bin)
+| ''Don't'' prolongate evolved variables.
 |-
 |}

@@ Line 67: / Line 67: @@
 |CCTK_INITIAL
 |State vector set at t=0
-|ks undefined (they are set during evolution)
+|ks, kTildes undefined (they are set during evolution)
 |-
 |CCTK_EVOL