CSEP 2.0 Developments - Revision history

Wsavran at 23:37, 28 June 2018

2018-06-28T23:37:42Z

← Older revision		Revision as of 23:37, 28 June 2018
Line 51:		Line 51:
	* comparison against csep1 simulations (use case for csep1 dataset)		* comparison against csep1 simulations (use case for csep1 dataset)
	** need method for comparing rate based forecasts and fault-based simulation based forecasts		** need method for comparing rate based forecasts and fault-based simulation based forecasts

			== Roadmap toward testing UCERF3 ==
			* describe specific steps required for testing UCERF3
			* essentially, previous sections written as actionable statements from previous section
			* include timeline

			== Conclusion ==
			* wrap up proposal with brief paragraph reiterating main points

Wsavran at 23:33, 28 June 2018

2018-06-28T23:33:01Z

← Older revision		Revision as of 23:33, 28 June 2018
Line 49:		Line 49:
	** northridge (unknown fault... hinterlands)		** northridge (unknown fault... hinterlands)
	* simple versus complex models		* simple versus complex models
	* comparison against csep1 simulations (use case for csep1 dataset)		* comparison against csep1 simulations (use case for csep1 dataset)
			** need method for comparing rate based forecasts and fault-based simulation based forecasts

Wsavran: /* Introduction */

2018-06-28T23:29:21Z

Introduction

@@ Line 1: / Line 1: @@
 [[CSEP_Working_Group|CSEP Working Group Home Page]]<br>
 __TOC__
 == Introduction ==
-Retrospective experiments of earthquake forecasts represent an important aspect of the CSEP software infrastructure. They provide significant insight into the performance of earthquake forecasting models and allow scientists to evaluate the performance of forecasts on historic earthquake sequences. The CSEP1 system is designed to support retrospective forecast experiments in addition to prospective forecasting. CSEP operates entirely in serial; meaning that both retrospective and prospective processing capabilities must happen sequentially. This sequential behavior is enforced within CSEP using locks that are placed on active directories during computation. While the serial nature of the system is not strictly enforced, working around the CSEPLocks require non-elegant hacks that violate the core concept of forecast groups within CSEP. This document explores the possibility of repurposing the current CSEP framework into a module to exclusively facilitate retrospective forecasting experiments.
+* state reasons for transitioning from CSEP1 -> CSEP2
 ; Guiding Principals
@@ Line 11: / Line 21: @@
 # Reproducibility
-The locks are used to prevent data contamination, and to prevent overwriting data by a different process. This is required because CSEP uses the same directory for all forecast models before moving forecast files to archive directories
+== Testing the Next Generation of Earthquake Forecasts ==

Wsavran: Wsavran moved page CSEP 1 Parallel Reprocessing to CSEP 2.0 Developments

2018-06-28T22:48:07Z

Wsavran moved page CSEP 1 Parallel Reprocessing to CSEP 2.0 Developments

← Older revision	Revision as of 22:48, 28 June 2018
(No difference)

Wsavran at 17:28, 4 June 2018

2018-06-04T17:28:17Z

← Older revision		Revision as of 17:28, 4 June 2018
Line 1:		Line 1:
	~~#REDIRECT~~ [[CSEP ~~1 Status~~]]		[[CSEP_Working_Group\|CSEP Working Group Home Page]]<br>
			__TOC__

			== Introduction ==
			Retrospective experiments of earthquake forecasts represent an important aspect of the CSEP software infrastructure. They provide significant insight into the performance of earthquake forecasting models and allow scientists to evaluate the performance of forecasts on historic earthquake sequences. The CSEP1 system is designed to support retrospective forecast experiments in addition to prospective forecasting. CSEP operates entirely in serial; meaning that both retrospective and prospective processing capabilities must happen sequentially. This sequential behavior is enforced within CSEP using locks that are placed on active directories during computation. While the serial nature of the system is not strictly enforced, working around the CSEPLocks require non-elegant hacks that violate the core concept of forecast groups within CSEP. This document explores the possibility of repurposing the current CSEP framework into a module to exclusively facilitate retrospective forecasting experiments.

			; Guiding Principals
			# Controlled Environment
			# Transparency
			# Comparability
			# Reproducibility

			The locks are used to prevent data contamination, and to prevent overwriting data by a different process. This is required because CSEP uses the same directory for all forecast models before moving forecast files to archive directories

Wsavran: Wsavran moved page CSEP 1 Parallel Reprocessing to CSEP 1 Status

2018-06-04T17:18:33Z

Wsavran moved page CSEP 1 Parallel Reprocessing to CSEP 1 Status

New page

#REDIRECT [[CSEP 1 Status]]