Differences between the following packages:
whereami: temporarily establish the widget you are in
and determine which condition you are using in a namespace
outside that of the main program
conditions_gui: temporarily establishes the widget in a private hash
within the namespace of the main program and hence accessible to all
local methods
disables or enables certain widgets
keeps track of flow index
decisions:
Judges conditions for making choices automatically
the namespace.
Superflows/tools read configuration files and write configuration files
using internal libraries, i.e. not Config-Simple
configuration parameters are found in arrays and not in hashes as for
the outside libraries of Config-Simple
Main: select_superflow
calls superflow_configs:
calls config_superflows: reads variables using readfiles.pm
calls param_widgets sets the variables for duplicated in a separate namespace too
How to add individual parameters to the GUI for a single specific superflow,
e.g. Project
(1) add new variables in
master file ~/big_streams/config/Project.config
and the local file ./Project.config
(2) Modify: package ~/big_streams/config/Project.pm
At line 179, in sub local_change_basic_dirs,
Add to line ~ 188: my ($geomaps_logic,$sqlite_logic,$gmt_logic);
Add new line ~209: $geomaps_logic = $control->set_str2logic($CFG[17]);
Add new line ~211: $gmt_logic = $control->set_str2logic($CFG[21]);
$Project ->{_geomaps_is_selected} = $geomaps;
Add new line ~ 270: _geomaps_is_selected => $geomaps_logic,
(3) add if clause: if ( $Project->{_geomaps_is_selected} ) {
}
(4) modify package: Project_spec.pm
modify line ~27 from _max_index => 'x',
to _max_index => 'x'+1,
(5) add ~ line 1454 my $GMT_GEOMAPS = $Project->{_GMT_GEOMAPS};
(6) sdd new sub if needed ~ 1043
sub GMT_GEOMAPS {
local_basic_dirs();
local_system_dirs();
my $GMT_GEOMAPS= $Project->{_GMT_GEOMAPS};
return ($GMT_GEOMAPS);
}
(7) ~ 8 add new line if needed:
$Project->{_GMT_GEOMAPS} = $GMT_GEOMAPS;
(8) ~523 add new line if needed:
$Project->{_GMT_GEOMAPS} = $GMT_GEOMAPS;
(9) ~ 363
# GMT GEOMAPS
my $GMT_GEOMAPS = $GEOMAPS.'/gmt/'.$DATE_LINE_COMPONENT_STAGE_PROCESS.'/'.$subUser;
(10) ~ 71
_GMT_GEOMAPS => '',
(11) ~ line 658
# GRASS GEOMAPS
my $GRASS_GEOMAPS = $GEOMAPS.'/grass/'.$DATE_LINE_COMPONENT_STAGE_PROCESS.'/'.$subUser;
How to Add a Completely New Superflow:
Example files needed: synseis (only master)
synseis.config (master and local versions)
synseis_config (only master)
synseis_spec.pm
Modify big_streams/config/synseis_config.pm
Change the number# \@{$superflow_config_names}[#];
This is the same sequence number as in
array: @superflow_config_names;
Look for array sequence in the package: L_SU_global_constants.pm
After Line 80.
for example for synseis: \@{$superflow_config_names}[8];
for example for Sseg2su: \@{$superflow_config_names}[9];
Modify misc/L_SU_global_constants
At: Line 85 change 'temp' to 'synseis'
Line 98 change 'temp' to 'synseis';
Line 22 change 'temp' to 'synseis';
Line 38 change 'temp' to 'synseis';
Modify LSU.pl: button options: append an additional
$args variable after the last $args[#] =
$superflow_select ->configure(
-menu => $top_menu_bar
);
$args[6] = $superflow_names->{_synseis};
$superflow_select ->command(
-label => $args[6],
-underline => 0,
-font =>$garamond,
-command =>[\&superflow_select,\$args[6] ],
);
Modify misc/config_superflows.pm
Lines 291 to 296 change 'temp' with 'synseis'
if ($$program_name_sref eq $superflow_names->{_synseis} ) {
# warning: must omit underscore
#print("config_superflows, set_program_name,superflow_names=$superflow_names->{_ProjectVariables}\n");
#print("config_superflows, set_program_name,alias superflow_names=$superflow_names->{_ProjectVariables}\n");
$name_sref = \$alias->{synseis};
}
( I have left a "temp" example you can replace);
Modify the main program, e.g. synseis ,
Sudipfilt,
Seg2su etc.,
so that it can import values from the configuration file
by adding the following lines, as an example for synseis:
use synseis_config;
my $synseis_config = synseis_config->new();
=head2 Get configuration information
=cut
my ($CFG_h,$CFG_aref) = $synseis_config->get_values();
=head2 set the different parameters
includes variables
=cut
my $data_name = $CFG_h->{synseis}{1}{data_name};
my $time_sampling_interval_s = $CFG_h->{synseis}{1}{time_sampling_interval_s};
my $depth_sampling_interval_m = $CFG_h->{synseis}{1}{depth_sampling_interval_m};
my $Ricker_endtime = $CFG_h->{synseis}{1}{Ricker_endtime};
my $Ricker_frequency = $CFG_h->{synseis}{1}{Ricker_frequency};
my $plot_density_max = $CFG_h->{synseis}{1}{plot_density_max};
my $plot_density_min = $CFG_h->{synseis}{1}{plot_density_min};
my $plot_depth_min_m = $CFG_h->{synseis}{1}{plot_depth_min_m };
my $plot_depth_max_m = $CFG_h->{synseis}{1}{plot_depth_max_m};
my $plot_time_min_s = $CFG_h->{synseis}{1}{plot_time_min_s};
my $plot_time_max_s = $CFG_h->{synseis}{1}{plot_time_max_s};
my $plot_velocity_min = $CFG_h->{synseis}{1}{plot_velocity_min};
my $plot_velocity_max = $CFG_h->{synseis}{1}{plot_velocity_max};
my $plot_reflection_coefficient_min = $CFG_h->{synseis}{1}{plot_reflection_coefficient_min};
my $plot_reflection_coefficient_max = $CFG_h->{synseis}{1}{plot_reflection_coefficient_max};
my $water_depth_m = $CFG_h->{synseis}{1}{water_depth_m};
my $plot_ss_amplitude_max = $CFG_h->{synseis}{1}{plot_ss_amplitude_max};
my $plot_ss_amplitude_min = $CFG_h->{synseis}{1}{lot_ss_amplitude_min};
Also create specs/synseis_spec.pm for superflows
Usually only the max index number has to be changes to the number of variables -1.
How Entry Labels, Values and Checkbuttons work:
Initially, when L_SU starts the checkbutton widgets and values
are green ("on") or red ("off"), and Labels and Entry Widgets are made blank.
e.g., using $param_widgets->initialize_labels
What happens when changes are made to individual parameters (Entry widget changes) -nothing
because currently a change is not assessed.
What happens now is that a subroutine ("param_widgets, changes") is called from the Entry widget whener
the user moves between entry widgets and the index value is detected.
This index could be used to compare the current and past value of the parameter space. However, historical
versions of the parameters would have to be stored, possible via the param_flow package or param_widgets package.
On the other hand it is simple if this index could be assumed to always represent a change and
to so to always confirm that "specs" files are not being violated.
Idea: build program behaviors using spec files
* good conditions for program 1 * bad conditions for program 1, e.g.,
SUXIMAGE perc_exists = true * absolute_clip exists = true (prod = 1) is a bad combination
perc_exists = true * absolute_clip exists = false (prod = 0) is a good combination
perc_exists = false * absolute_clip exists = true (prod = 0) is a good combination
SYNSEIS superflow: Ricker_exists = true * real_source_exists = true (prod = 1) is a bad combination
Ricker_exists = false * real_source_exists = true (prod = 0) is a good combination
Ricker_exists = false * real_source_exists = true (prod = 0) is a good combination
incompatible index_pairs_array= [0 0 1 4 6 8]
e.g., incompatible_items_aref A [1] * incompatible_items_aref B [4] (prod = 1) or (prod = 0)
where $good = 0 and $bad = 1
so if ($good) the proceed
so if ($bad) provide error message
For the case of Superflows, redisplay the values that exist stored in param_flow:
$param_widgets->set_values($TkPl_SU->{_values_aref});
$param_widgets->redisplay_values();
For the case of regular user-made flows:
$param_widgets->set_values($TkPl_SU->{_values_aref});
$param_widgets->redisplay_values();
redisplay_values controls the behavior of the entry widget. Currently each entry widget returns its
own index. TODO This index could be used to check the appropriateness of the change to the Entry value
every time it is redisplayed. For this situation the values and labels for reach program should be in a predictable order
(an array reference).
Also, whenever a seismic unix program is clicked within the flow_listbox (left or right)
(NOT the seismic unix selection listbox), the parameters are redisplayed
sub called: flow_select (main, flow_select)
If selected, sub flow_select always assumes a change has been made to one of the parameters
and runs: sub local_check4changes(); (main, flow_select, local_check4changes)
sub local_check4changes:
-finds out which program was just touched
-assumes all prior programs touched have
modified parameters
-updates the touched program's stored values
The only place that a flow is checked for how correct its parameters are will be at the
time the perl file is run. Programs and their paramters are checked out against the requirements of the spec
files for the individual programs e.g., suximage.spec
Q. how many programs are there?
data - 25
datuming - 4
display - 44
filter - 20
inversion - 2
metadata - 29
migration - 23
misc - 58
model - 48
NMO_Vel_Stk - 36
par - 61
picking - 3
shapeNcut - 26
statsMath - 27:w
transform - 24
well - 6
Total 436 programs
Q What is the size of the project
57M big_streams
124K c
6 checks
347K configs
163K developer/code
49K geopsy
6 git_commands/.git/refs/heads
220K gmt
3.7K images
35K LICENSE
276K log.txt
317 L_SU
12K L_SU_project_selector.pl
79K L_SUV0.3.6.pl
11K messages
3.8M misc
6 reqs
41K specs/specs
420K specs
11K sqlite
882K sunix
9.3K t
3.0K unix
22 waveform
Q. How does Project Selector find the program name