Thursday, October 8, 2009
XYZ changed to NEU in daily and realtime RDAHMM
The daily and realtime RDAHMM portlets have been updated so that the "Current X", "Current Y", "Current Z" tags are changed to "North", "East" and "Up".
Monday, September 7, 2009
Modifications to the evaluation process of daily RDAHMM
Previously, the evaluation process of daily RDAHMM only takes a station's GPS data from 2006-10-01 to "today" as input.
We now extend the evaluation input to include all of a station's GPS data since 1994-01-01; i.e., including input data in the modeling process. For any specific station, the state change sequence in the evaluation process for the modeling time section is expected to be the same as the sequence in its modeling result. Further, if any input data is missing between the last "data-available date" of the modeling time section and the first "data-available date" in the evaluation time section, data duplicated from the last "data-available date" of the modeling time section is used to fill the "data-missing" section.
We now extend the evaluation input to include all of a station's GPS data since 1994-01-01; i.e., including input data in the modeling process. For any specific station, the state change sequence in the evaluation process for the modeling time section is expected to be the same as the sequence in its modeling result. Further, if any input data is missing between the last "data-available date" of the modeling time section and the first "data-available date" in the evaluation time section, data duplicated from the last "data-available date" of the modeling time section is used to fill the "data-missing" section.
Monday, August 17, 2009
Tooltips Added to Simplex, Disloc, and GeoFEST
GeoFEST, Disloc, and Simplex fault parameter forms now have tool tips to explain the parameters. GeoFEST layer parameters also have tool tips.
Sunday, April 12, 2009
Modifications to daily RDAHMM service for supporting JPL data source
We have modified the daily RDAHMM service in the following way so that other data sources can be supported in a flexible way:
1. We run one service process for each data source;
2. Corresponding to different data sources, different directories will be used to save the daily RDAHMM analysis results. Besides, different arguments should be used for querying the input GPS data for different data sources;
3. On start up, a service process will receive the path to a property file as an argument. This file contains information such as the data source, pre-processing treatment, directory for saving the results, and GRWS query arguments for this process. The process will analyze the property file, and thus do analysis to the specified data source, using the right corresponding query arguments, pre-processing treatment, and output directory.
1. We run one service process for each data source;
2. Corresponding to different data sources, different directories will be used to save the daily RDAHMM analysis results. Besides, different arguments should be used for querying the input GPS data for different data sources;
3. On start up, a service process will receive the path to a property file as an argument. This file contains information such as the data source, pre-processing treatment, directory for saving the results, and GRWS query arguments for this process. The process will analyze the property file, and thus do analysis to the specified data source, using the right corresponding query arguments, pre-processing treatment, and output directory.
Support for JPL data source added to Daily RDAHMM portlet
Support for JPL data source has been added to daily RDAHMM portlet. We added a separate jsp page, DailyRdahmm_jpl.jsp, to show the results of JPL data source, and added a navigation rule in the portal configuration file, faces-conf.xml, to navigate betweent the pages for SOPAC data source and JPL data source. Now there is a link on each page pointing to the other page, so the user can click this link to view results for the other data source. Updates have been applied to the server at gw11.quarry.iu.teragrid.org:
http://gw11.quarry.iu.teragrid.org:8080/gridsphere/gridsphere
http://gw11.quarry.iu.teragrid.org:8080/gridsphere/gridsphere
Monday, March 23, 2009
Daily RDAHMM portlet modified corresponding to the video service
We have modified the daily RDAHMM portlet so that it now links to a video file made by the daily RDAHMM video service, which will always be in mp4 format.
Monday, March 16, 2009
Daily RDAHMM Video Web Service Completed
And here's the design document:
To make daily RDAHMM movies with h264 video format, which is the most portable format across Linux, Windows and Mac platforms, we decide to create a DailyRDAHMMVideoService web service sitting on a machine where everything is OK for making h264 videos, and answering the requests from DailyRDAHMMService, and returning links to videos newly created.
Pre-requisite:
mencoder installed with support for x264 options
mp4BOX installed
So far the only machine that satisfies these requirements is Xiaoming's machine with IP address 156.56.104.161.
Requirements for DailyRDAHMMVideoService web service:
We call DailyRDAHMMVideoService the "video service" for short. This service is supposed to support the creation of daily RDAHMM movies for different data sources (SOPAC, JPL, etc.), and different pre-process treatment methods to input data (with vs. without missing data treatment). Given a data source, a treatment method, a URL to the analysis result XML file of that data souce, and a pair of start and end date, the video service will create a movie for the period between the start and end date, according to the result XML file specified in that URL, and return a URL to the created video. More specificly, the video service provides a web service method "String makeVideo(String dataSource, String preProcTreat, String resultURL, String startDate, String endDate)", which makes the requested video, and returns the URL string of the video.
Design Issues:
1. Directory seperation. Since we want to support different data sets and input treatment methods, the analysis results and corresponding map pictures for these different parameters will be different, so we need to separate the directories for different parameter combinations. Let denote the top directory for storing the pictures and temporary video files, we use [picDir]/[dataSouce]/[preProcTreat] for different parameters.
2. Quick response. To respond quickly to the client, we apply asynchronous process to its request. First, the video service will check if the parameters are valid, e.g., whether the given data source and treatment methods are supported. If not, a URL pointing to another method of the video service, "String getErrorMsg(int msgNum)" will be returned to the client, so that when the client opens that URL, a proper error message will be returned. If the parameters are valid, a URL will be constructed immediately according to these parameters and returned to the client, before the video is actually created. That is, we assume that there will be no errors in the process of creating the video. After enough debugging, we think this will not cause very serious problems: anyway, putting an invalid URL on the portal in rare cases will not be the end of the world.
3. Requests buffering. In order to answer multiple requests asynchronously in a short time, we buffer these results in a list, and use a separate thread to process them. This separate thread is sleeping when there is no request to process, and will be waken up for new requests.
4. Avoiding redundant work. To avoid creating video frames for any period for multiple times, we save the start date (which will always be 1994-01-01) and end date of the last video created. Upon every new request, the video service will check its start and end date. If these dates falls in between the start and end date of the last video, we just return the URL for the last video. A new video will be created only if the end date is later than the end date of the last video, since all starting dates are supposed to be no earlier than 1994-01-01. Besides, if the month number of the given end date minus 2 is later than the month number of the historical video, the historical video is updated and extended to the month according to the given month number minus 2. For example, if the end date of the historical video is 2008-07-31, and the end date of the requested video is 2008-11-22, then the historical video will be updated to 2008-09-30 first, and then the new video is created based on the new historical video.
To make daily RDAHMM movies with h264 video format, which is the most portable format across Linux, Windows and Mac platforms, we decide to create a DailyRDAHMMVideoService web service sitting on a machine where everything is OK for making h264 videos, and answering the requests from DailyRDAHMMService, and returning links to videos newly created.
Pre-requisite:
mencoder installed with support for x264 options
mp4BOX installed
So far the only machine that satisfies these requirements is Xiaoming's machine with IP address 156.56.104.161.
Requirements for DailyRDAHMMVideoService web service:
We call DailyRDAHMMVideoService the "video service" for short. This service is supposed to support the creation of daily RDAHMM movies for different data sources (SOPAC, JPL, etc.), and different pre-process treatment methods to input data (with vs. without missing data treatment). Given a data source, a treatment method, a URL to the analysis result XML file of that data souce, and a pair of start and end date, the video service will create a movie for the period between the start and end date, according to the result XML file specified in that URL, and return a URL to the created video. More specificly, the video service provides a web service method "String makeVideo(String dataSource, String preProcTreat, String resultURL, String startDate, String endDate)", which makes the requested video, and returns the URL string of the video.
Design Issues:
1. Directory seperation. Since we want to support different data sets and input treatment methods, the analysis results and corresponding map pictures for these different parameters will be different, so we need to separate the directories for different parameter combinations. Let denote the top directory for storing the pictures and temporary video files, we use [picDir]/[dataSouce]/[preProcTreat] for different parameters.
2. Quick response. To respond quickly to the client, we apply asynchronous process to its request. First, the video service will check if the parameters are valid, e.g., whether the given data source and treatment methods are supported. If not, a URL pointing to another method of the video service, "String getErrorMsg(int msgNum)" will be returned to the client, so that when the client opens that URL, a proper error message will be returned. If the parameters are valid, a URL will be constructed immediately according to these parameters and returned to the client, before the video is actually created. That is, we assume that there will be no errors in the process of creating the video. After enough debugging, we think this will not cause very serious problems: anyway, putting an invalid URL on the portal in rare cases will not be the end of the world.
3. Requests buffering. In order to answer multiple requests asynchronously in a short time, we buffer these results in a list, and use a separate thread to process them. This separate thread is sleeping when there is no request to process, and will be waken up for new requests.
4. Avoiding redundant work. To avoid creating video frames for any period for multiple times, we save the start date (which will always be 1994-01-01) and end date of the last video created. Upon every new request, the video service will check its start and end date. If these dates falls in between the start and end date of the last video, we just return the URL for the last video. A new video will be created only if the end date is later than the end date of the last video, since all starting dates are supposed to be no earlier than 1994-01-01. Besides, if the month number of the given end date minus 2 is later than the month number of the historical video, the historical video is updated and extended to the month according to the given month number minus 2. For example, if the end date of the historical video is 2008-07-31, and the end date of the requested video is 2008-11-22, then the historical video will be updated to 2008-09-30 first, and then the new video is created based on the new historical video.
Subscribe to:
Posts (Atom)