Is there a way to query for the available models?

[krischer]

I could only find the list here: http://ds.iris.edu/ds/products/syngine/#models

[CTrabant]

I would like to be able to create a list of models with the most important details of each extracted from the "info" route of each model server (e.g. http://service.iris.edu/irisws/syngine/1/info?model=ak135f) and return a small JSON structure.

I need some help making sure I understand the information in the "info" content. Here is what I'm thinking in terms of content (with "info" names):

• name (already known)
• frequency range supported (dt to ?)
• maximum sampling rate (sampling_rate ?)
• maximum seismogram length (length ?)
• components (components)

Questions:

• Are these the correct fields?
• How is the largest frequency for a model known?
• Is external_model_name something that will be populated and useful?

[CTrabant]

ping @krischer @sstaehler ?

[krischer]

They are almost correct.

• dt and sampling_rate are inverse to each other and denote the actual sampling rate of the database. This is also the lower bound of the allowed frequencies for the resampling.
• period is the dominant period, i.e. approximately the smallest period that can still be accurately simulated. The database are accurately simulated up to a period of approximately 100 seconds at which point physical effects that are not simulated by AxiSEM start to become important. @martinvandriel @sstaehler: do you have some more accurate numbers? So the supported period range is approximately period to 100 seconds for all databases.
• length is the maximum seismogram length in seconds. This includes a couple of seconds before the peak of the source time function.
• The external_model_name will not be useful for the syngine service.
• I think the min and max radius parameters should also be included in the summarizing JSON structure.

[CTrabant]

Check it out: http://service.iris.edu/irisws/syngine/1/models

The value for max_period is hard-coded to 100. Is there no internal documentation of the lowest frequency supported by a database?

Here is the mapping in code, infohref is a hash-representation of the JSON from an info request:

$modelsummary{$model}{components} = $infohref->{components}; $modelsummary{$model}{planet_radius} = $infohref->{planet_radius}; $modelsummary{$model}{min_radius} = $infohref->{min_radius}; $modelsummary{$model}{max_radius} = $infohref->{max_radius}; $modelsummary{$model}{length} = sprintf "%.0f", $infohref->{length}; $modelsummary{$model}{min_period} = $infohref->{period}; $modelsummary{$model}{max_period} = 100; $modelsummary{$model}{max_sampling_period} = sprintf "%.6f", $infohref->{dt};

[martinvandriel]

@krischer is correct. The reason for saying 100s somewhat handwavingly is that we do not include gravity and coriolis force, and this 100s is where these effect start to be important (I did not test this myself, but this seems to be what the old farts agree on).

[krischer]

@CTrabant It might be worthwhile to replace the planet_radius, min_radius, and max_radius parameters with max_event_depth which (for users of the syngine service) is the interesting parameter.

For all the planned databases that would be sufficient. Once water planets can be simulated with AxiSEM that might have to rethought but that is still far in the future.

[CTrabant]

Agreed. I've replaced the radius values with max_event_depth as the difference between max_radius and min_radius. That was my initial thinking anyway, but I had the other-plant usage in mind but those values can be exposed later if needed.

I also changed max_period to have a value of "~100" to indicate the handwavyness.

Thanks for the info and suggestions, let me know if there are more things to consider.