CSEP 1 STEPCoulombQuickFix

Introduction

RFC002 discusses the issues observed with the STEPCoulomb model in the CSEP New Zealand testing center. CSEP provides a computational infrastructure to perform and evaluate both prospective and retrospective earthquake forecasting experiments. In regards to a retrospective forecasting experiment, it was observed that the STEPCoulomb model installed in CSEP did not produce the expected output for the Darfield Experiment -- a forecasting experiment of the 2010 Christchurch Earthquake sequence.

The STEPCoulomb model represents a hybrid model consisting of a statistical STEP model and a physics-based Coulomb stress model. The executable that computes the STEP forecast obtains a Coulomb mask based on available slip models, and uses the information contained from the Coulomb stress model to provide physical constraints to the statistical STEP (short-term earthquake prediction) forecast. The STEPCoulomb forecast should produce two forecast outputs: (1) STEP forecast, and (2) STEPCoulomb forecast, which can be compared to determine the pairwise efficacy of the two forecasting models.

This document is laid out as follows: Problem Statement provides a description of the problems as communicated by the science groups to SCEC IT; and Proposed Solution provides an explanation of the proposed solution to the problem outlined in the problem statement.

Problem Statement

1. Overview

It was suspected the STEPCoulomb forecast, computed by the New Zealand CSEP testing center, did not produce the expected outputs. This issue affects an on-going manuscript review, so an urgent response is needed. The problem was confirmed by comparing the STEP forecast with the supposed STEPCoulomb forecast and determining that there were no differences between the forecasts. Computing differences between the two forecasts indicated that both files were identical. It is expected that the physics-based Coulomb stress model should influence the rates forecasted by the statistical STEP model.

2. Detailed Explanation

When invoking the STEPCoulomb model, CSEP makes sequential, external calls to two executables: (1) STEPCoulomb and (2) step-aftershock. In model (1), finite-fault slip models are used to produce bitwise masks based on Coulomb stress calculations. The masks produced by model (1) are meant to be read by model (2), and used to update the forecasted rates. To facilitate the interchange of these executables, CSEP creates 'CSEP-specific' input files to define the file paths for forecast files and associated metadata on the CSEP filesystem. For example, the file located at

/home/csep.canterbury/DarfieldExperiment/bestAvailableTC/batch/runs/csep/2015_11/20151109214739/pid_3368/scec.csep.STEPCOULOMBOneDay.CoulombPart_STEPCOULOMBOneDay_control.dat.1447165313.806906.1   

provides the CSEP-specific inputs to forecast model (1). An example input file for (2) can be found at:

/home/csep.canterbury/DarfieldExperiment/bestAvailableTC/batch/runs/csep/2015_11/20151109214739/pid_3368/scec.csep.STEPCOULOMBOneDay.STEPCOULOMBOneDay_control.dat.1447165313.743799.1

If we compare the contents of this input file with the source code of executable (2), we find that there is a bug which would produce the issue described in the overview section. The code below shows the RegionDefaults.setCsepParams(...) function that is responsible for reading the CSEP generate input file and overwriting the default parameters of the model.

  public static void setCsepParams(String filePath)
   throws FileNotFoundException, IOException
 {
   logger.info(">> setCsepParams filePath " + filePath);
   
   ArrayList<String> fileLines = FileUtils.loadFile(filePath);
   
   String line = (String)fileLines.get(0);
   logger.info("catalog start date " + line);
   EVENT_START_TIME = parseCsepTime2Cal(line);
   logger.info("EVENT_START_TIME " + dateformater.format(EVENT_START_TIME.getTime()));
   line = (String)fileLines.get(1);
   logger.info("catalog end date " + line);
   forecastStartTime = parseCsepTime2Cal(line);
   logger.info("forecastStartTime " + dateformater.format(forecastStartTime.getTime()));
   line = (String)fileLines.get(2);
   logger.info("forecast length " + line);
   forecastLengthDays = Integer.parseInt(line.trim());
   line = (String)fileLines.get(3);
   logger.info("catalog input file " + line);
   cubeFilePath = line;
   line = (String)fileLines.get(4);
   logger.info("forecast output file " + line);
   outputAftershockRatePath = line;
   
   line = (String)fileLines.get(5);
   logger.info("background rate input file " + line);
   BACKGROUND_RATES_FILE_NAME = line;
   
   line = (String)fileLines.get(6);
   logger.info("Coulomb input file " + line);
   coulombFilterPath = line;
 }

We see that the output file name is assigned to the variable outputAftershockRatePath which defines the output for the pure STEP forecast. For more details on this aspect, view the method STEP_main.saveRatesFile(...). It shows that outputAftershockRatePath is used to define the output of the pure STEP forecast. The Coulomb portion of the STEPCoulomb model is implemented in "ApplyCoulombFilter.applyFilter(...)". The IO portion of this method is shown below:

    try
   {
     FileWriter fr = new FileWriter(RegionDefaults.outputCoulombRatePath);
     bgRegionSize = bgLocList.size();
     for (int k = 0; k < bgRegionSize; k++)
     {
       Location bgLoc = bgLocList.getLocationAt(k);
       
       HypoMagFreqDistAtLoc bgDistAtLoc = bggrid.getHypoMagFreqDistAtLoc(k);
       if (bgDistAtLoc != null)
       {
         int numForecastMags = 1 + (int)((RegionDefaults.maxForecastMag - RegionDefaults.minForecastMag) / RegionDefaults.deltaForecastMag);
         for (int index = 0; index < numForecastMags; index++)
         {
           double mag = RegionDefaults.minForecastMag + index * RegionDefaults.deltaForecastMag;
           
           double wrate = bgDistAtLoc.getFirstMagFreqDist().getIncrRate(mag);
           if (wrate == 0.0D) {
             wrate = 1.0E-11D;
           }
           fr.write(locFormat.format(bgLoc.getLongitude() - RegionDefaults.gridSpacing / 2.0D) + "    " + locFormat.format(bgLoc.getLongitude() + RegionDefaults.gridSpacing / 2.0D) + "    " + locFormat.format(bgLoc.getLatitude() - RegionDefaults.gridSpacing / 2.0D) + "    " + locFormat.format(bgLoc.getLatitude() + RegionDefaults.gridSpacing / 2.0D) + "    " + RegionDefaults.MIN_Z + "    " + RegionDefaults.MAX_Z + "    " + magFormat.format(mag - RegionDefaults.deltaForecastMag / 2.0D) + "    " + magFormat.format(mag + RegionDefaults.deltaForecastMag / 2.0D) + "    " + wrate + "     1\n");
         }
       }
     }
     fr.close();
   }
   catch (IOException ee)
   {
     ee.printStackTrace();
   }

We see that a FileWriter is created using the filepath of "RegionDefaults.outputCoulombRatePath" which is hard-coded to be "/coulombRates.txt." As seen by the "RegionDefaults.setCsepParams()" this location is not overwritten by the CSEP generate input files. This indicates that the Coulomb Rates are not being correctly stored to the CSEP file system and are being overwritten with each subsequent run.

Proposed Solution

[TODO]