Custom Query (454 matches)

The Time dependent UCERF2 epistemic list ERF currently does not allow you to set the start year, because it extends UCERF2_TimeIndependentEpistemicList which creates it's time span object with start time units of "None." The easiest fix would be to set the start time units to "Years" in UCERF2_TimeIndependentEpistemicList but I don't know if this would have any other unforeseen consequences.

Peter - this may definitely affect your current work.

I've been getting weird (non-reproducible) exceptions while doing threaded hazard calculations (using a single ERF object, and an IMR object for each thread). I traced it down to the rupture distance methods not being thread safe. They use cached values to avoid recalculating distances for the same site, but are not synchronized. For example

(from AbstractEvenlyGriddedSurface?.java)

public double getDistanceRup(Location siteLoc){
	if(!siteLocForDistCalcs.equals(siteLoc)) {
		siteLocForDistCalcs = siteLoc;
		setPropagationDistances();
	}
	return distanceRup;
}

Ned - in case you don't understand the issue here, consider this scenario: Imagine that thread1 calls getDistanceRup(loc1) and loc1 is already in the cache. It will first check to see if it is match, which it is. But then thread2 could come along and call the same method with another location (loc2), which resets the propogation distances. This could all happen before thread1 gets to the "return distanceRup" statement and it could erroneously return the distance from loc2 instead of loc1. This is very dangerous (and is already causing a problem with multithreaded calculations)

I see a couple ways of dealing with this:

1. slap the "synchronized" keyword on all such methods. this quickly solves the problem, but removes any efficiencies from the caching in a multithreaded environment as different threads will be constantly resetting the cached value.
2. use a cache that can store multiple values - maybe remembering the last 10 sites where distances were calculated. this could also be tuned to the number of available CPUs, so if your computer has 24 cores (as some compute nodes that I use do), the cache size would default to 24. You could also specify this as java property value (-DRuptureSurface.cacheSize=24 for example).
3. similar to (2) above, but instead of implementing it in each class, first strip out all caching from individual rupture surfaces. Then create either a wrapper class which handles caching, or an AbstractRuptureSurface? class which all RuptureSurface? instances would extend which would handle caching.

This is very important and should be dealt with soon. Thoughts?

I noticed an apparent bug in the caching for GriddedSubsetSurface? while investigating #390. DistanceX uses a different cache but the getDistanceX method was being called with the regular cached location, siteLocForDistCalcs, instead of siteLocForDistXCalc. This means that our distance X calculations have potentially been off any time that distance X is calculated before any of the other distance metrics for a given site. Any results since the new surface implementation was added where values for multiple sites were calculated could be affected by this bug.

public synchronized double getDistanceX(Location siteLoc){
	if(!siteLocForDistXCalc.equals(siteLoc)) {
		siteLocForDistXCalc = siteLoc;
		distanceX = GriddedSurfaceUtils.getDistanceX(getEvenlyDiscritizedUpperEdge(), siteLocForDistCalcs);
	}
	return distanceX;
}