What I thought I heard on my Tuesday in Menlo Park ... 1) We reviewed the design, focusing primarily on the issues of databases and waveform access for post-processing and review. The particular issue of concern was loss of connectivity between Berkeley and Menlo Park and how that situation will effect our operations. We struggled with this. Loss of connectivity could be 1 min, 1 hour, 1 day, or 1 week. Or more in the absolutely worst case. One proposal was to have both systems, whether master or slave, generate waveform request cards/perform waveform retrieval. Each system, in this case, would attempt to harvest waveforms for all stations. In normal operations, the events generated by each system would be similar and therefore the waveforms retrieved would be similar. In non-normal operations, each system might only retrieve its own local waveforms, initially, although presumeably the full set would be collected once connectivity is restored. This approach does duplicate waveforms, unless a cleanup proceedure is developed to go back and delete the waveforms associated with 'backup' events after some period of time (90 days, let's say). So to step back, there were 2 problems we are trying to address -- access to (at least) local waveforms for review and post-processing and ensuring that no data are lost during an extended outage. This issue needs more thought. A second issue we discussed was where Jiggle would access waveforms for review. The current plans is that Jiggle should access the data center for the authoritative copy of the waveforms - but we need to test the performance of Jiggle: - Jiggle using local database and local waveforms - Jiggle using local databae and remote waveforms There was some discussion about whether Menlo would normally use the Internet or the T1s to access to waveforms; there is more bandwidth over the "Internet" but one could reconfigure Jiggle to use the T1 if needed. 2) Resources We discussed the computer resources necessary to build the system and the question of what resources would need to be redundant. -- Machines for the digitizer and for the waveservers -- Probably (subject to testing) one machine for picking/wda&rad&ada/statrig but two total for redundancy/reliable access to this service -- at least one machine for the real-time processing (but probably two for separating the mt/ff/ShakeMap) -- One machine for the local data center service 3) Network services We discussed one of the network services in some detail - the reduced amplitude time series. This is one we want to get started on since it also plays into CISN development. We first discussed the depth of the various data areas. 2 hours for the WDA seemed approriate; with 30 minutes for the ADA. See the attached figure for our draft design. Since we intend that Berkeley and Menlo each run 2 machines producing the reduced amps, our goal is to have all 4 machines feed the adas that will ultimately be use for producing magnitudes and amplitudes for ShakeMap. We need: ew2ada - so that Menlo can implement this system modifications to rad - so that it can begin producing amplitudes on even 5 sec boundaries modifications to adafill - so that it can take multiple sources and fill in the amplitudes seamlessly For the amp server, we have some options. Pete put together a model using import/export that could be used (with some modification) when we are ready to do this. Alternatively, Doug is working on the free orb software and that may be available when we are ready to start this up. Note: Pete has raised concerns about how this will scale - for example, as we add feeds from Southern California and perhaps from other networks. For example, does SoCal provide 1 feed of their ADA to Berkeley and Menlo each or 2 feeds each - one from the master and slave systems? This needs more thought - see the proliferation of lines of the diagram .... 4) Md and eqprelim/eqproc Perhaps unwisely, we took on this topic in the afternoon. There are two issues here. One is that we had not considered the impact of the two hypocenter sources in our model and the other was the idea of cutting the Md computation free from the hypoinverse calculation in order to expedite Ml/Me, ShakeMap, other processing. First, the fast and slow hypocenter source caused a lot of head scratching. In the current system, the fast hypocenters are used ONLY to go out the to Web pages. They show up as events without magnitude. The version 0 hypocenters are generated when an event has 25 picks. In some cases, the event will be destroyed by binder and remade as another event. The idea of using the fast hypocenter to expedite processing was discussed, but the limitations of the current digital station infrastructure rules that out (because our current experience shows problems with calculating Ml for small events). So the interim solution was to 1) review how SoCal uses version number in the event table, with the goal of using that table to differentiate between these sources 2) the EC would publish V0 messages. The alarm system would be one consumer of the alarm messages and would use this to put the events in qdds. 3) we would need to develop a module that acted as a deadman switch. It would consume V0 and V1 messages. If it did not see a V1 message for a V0 event after 5 minutes, it would issue a delete message for the V0 event. 4) we need to make sure that eqproc/eqprelim pass through the delete messages from binder. 5) EC would use event id to make associations between v0 and v1 only. (Since we decided we would delete v0 events that were not followed by a v1 event). For the moment, we proposed to leave the eqproc as it is. Md would be computed as part of hypoinverse. Modifications are needed to hyp2ps in order to accomodate the Md message (and to fill in more of the hypoinverse information). Presumeably modifications are needed in the EC to pass this information on to the database. This model will not work for SoCal, given the desire for speed. We believe that they have only 1 pipe, and that the hypocenters are pulled out after 1 minute or so. So this needs more thought. After the return to Berkeley, Pete and Lind brainstormed a little bit. Could we develop a middle path, something in betweem eqprelim and eqproc, that pulls the hypocenter and the existing codas (what ever they are) after 1 minute. If the event is small, most of the codas will be complete and the resulting Md would be ok. If the event is large, well, that is typically the events that we would want to have Ml/Mws for anyway. This would require some development and we would have to consider whether this replaces eqprelim or whether we are adding another stovepipe (sausage).