App-SeismicUnixGui
view release on metacpan or search on metacpan
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
Abbreviations in this file:
',' are methods/subroutines within a module/package
';' separates entire modules/packages
.pm is left out in reference to module names in what follows
use sgy txt bin su as extensions to data in
INDEX to this file
Two types of flow types exist-- those built by the user and those that are pre-built 'superflows'.
User-built flows ( 4 colors) diverge from 'grey_flow.pm', pink_flow.pm, etc.
sunix_select.pm uses exclusively 'neutral_flow.pm'
Superflows diverge from user-build flows in L_SU via pre_built_superflow.pm
User-built flows can be of 4 colors.
The namespaces for each color flow and superflows are independent,
for the most part (TODO), of other parts of the program.
There are two sets of dialogs for interacting with files and directories.
The "Run" and "Save" have their OWN logic-separated paths:
L_SU, run_button and L_SU, save_button
for superflows versus user-built flows, including parameter_widgets etc.
The SaveAs and Data and Flow buttons have their own logic path through
L_SU, FileDialog_button
If there are superflow bindings for opening data files, then these use
L_SU, pre_built_superflows,
pre_built_big_stream->select( )
_FileDialog_button,
pre_built_big_stream,select,binding->set() (where actual binding takes place!)
sub _FileDialog {
In file_dialog,
iFile->get_Path gets directory path binding uses.
BINDINGS-for DEVELOPERS
User-built programs containing bindings (e.g., MB3) (e.g.,those that use sunix programs)
sunix programs use _FileDialog_button to find files.
'color'_flow
_FileDialog_button module lies within each of the 'colored' flows: e.g. grey_flow.pm, pink_flow.pm, etc.
The type of files that can be opened are (1) user_built flows {_Flow},
2) data files e.g. su, binary, par, and plain text files {_Data} [_Data_PL_SEISMIC}
and (3) pre_built superflows and directories {_Path}
Q. For a sunix program with a binding how does the FileDialog get activated?
Individual programs can have bindings, e.g. segyread has the file|tape option
bound to automatically open the directories that contain segy files
(See Project_config.pm for a
full description of the many pre-defined directory locations)
Q. What are the differences between the Save methods between user-built flows and superflows
A. Superflows use L_SU->save_button
A. user-built flows use color_flow.pm->save_button
The sequence of programs during a 'Save' is as follows:
main
L_SU
color_flow.pm->save_button
Q. What are MB1 bindings for colored listboxes?
Q. How are colored flow listboxes selected?
Q. how do I select a colored flow listbox?
When MB1 is clicked over a colored listbox flow (grey, pink, green or blue)
then that colored flow is selected;
e.g. L_SUV0.X.C,_L_SU_flow_bindings(color,flow_select);
L_SU->user_built_flows(flow_select), grey_flow->flow_select
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
(inherited by gui_history)
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
All values that enter have a chance of being changed.
Internally a new set of private variable siscast from the hash that is entered.
decisions:
Judges conditions for making choices automatically in
the namespace.
Big streams/Superflows/Tools read configuration files and write configuration files
using internal libraries.
Configuration parameters are found in arrays.
3rd-party library like Config-Simple is now deprecated.
Other superflows can have a local configuration file( i.e., iSpectralAnalysis.config)
For example, make sure that your local configuration file also gets updated accordingly if you change
the master iSpectralAnalysis.config
Main, _L_SU_superflows calls pre_built_superflow
pre_built_superflow, select calls config_superflows
config_superflows, get_local_or_defaults calls big_streams_param
big_streams_param extends su_param
su_param reads variables using readfiles.pm
readfiles.pm,configs reads in values
calls param_widgets sets the variables for duplicated in a separate namespace too
Question: How do I add individual parameters to the GUI for a single specific superflow,
Example 1: parameter "geopsy" in "Project"
(1) add new variables in
master file: ~/configs/big_streams/Project.config
and in the files: ~/.L_SU/configuration/active./Project.config
~/.L_SU/configuration/"project_name"/Project.config
N.B. In some superflows, only the local configuration file has to be modified.
(2) Modify: package ~/configs/Project_config.pm
At line ~ 52, add key and value to $Project hash: _geopsy_is_selected => '',
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
FileDialog_button (with value 'Flow')
Q. What sequence of programs are used when deleting (Delete) a pre-existing perl file flow,
main,
_L_SU
L_SU
FileDialog_button (with value 'Delete')
_FileDialog_button_Delete
neutral_flow
file_dialog
FileDialog_director
_set_FileDialog2user_built_flow
_user_built_flow_Delete_perl_file
_FileDialog,
Q. What sequence is used to open a Data-type perl file ('Data') or a user-built 'Flow'
A. Opening a perl file or a user-built 'Flow' involves the following sequence:
main,
FileDialog_button, _L_SU,
L_SU,set_hash_ref
L_SU,FileDialog_button
color_flow
FileDialog_button, ....
_perl_flow
_add2flow
_flow_select2save_most_recent_param_flow
updateNsave_most_recent_param_flow (for 'flow_select')
_flow_select_director
(widget from any color_flow_href values are all present and
displayed on the GUI)
file_dialog,
FileDialog_director
_set_FileDialog2user_built_flow
_user_built_flow_open_data_file ,
or _user_built_flow_open_perl_file,
_FileDialog,
_user_built_flow_close_data_file,
or _user_built_flow_close_perl_file
control, set_file_name,
remove_su_suffix4sref;
get_w_single _quotes(remove suffix, add single quotes);
Opening a Data file from within a superflow can follow two routes:
Route 1: Directly from the GUI menu selection of "File/Data" (deprecated)
Route 2: Indirectly, via bindings defined in spec files:
L_SU, _FileDialog_button (for MB3 bindings)
Superflow bindings use this subroutine exclusively:
binding, set
binding is called when the dialog type = Data and we are dealing with a superflow
How do we separate namespaces between pre-built superflow usage and user-built flows?
Some dialog widgets are used exclusively for superflows ( superflow selection)
Other widgets are used exclusively for user-built flows (sunix selection,add2flow ), Flows and SaveAs
Color distinguishes regular user-built flows where sunix-selection is marked with a neutral color.
Some options have no color (Flow) but do have a flow-type assigned within LSU.
Dialog types
Dialog types can be Data (superflow and user-built flows, directly selected or bound)
Flow or 'SaveAs'( are exclusively for user-built perl flow)
Save can be for superflows or user-built flows.
Flow types
Flow types can be flow_type can be 'user_built' or 'pre_built_superflow'
L_SU sets flow types and colors plus listbox logicals (e.g., _is_listobox_grey_w = 0 or false)
N.B., Historically, some conditions are repeated using different variable names, e.g.,
is_pre_built_superflow, is_superflow and is_superflow_select_button
Q: (NOW DEPRECATED and AUTOMATED-- See perldoc of ~/developer/code/sunix/README.pm)
10.06.21 Q: How do we add another seismic unix module or seismic unix program to L_SU?
run (1) sudoc2pm.pl followed by (2) sudoc2pm_updates.pl
Details:
(1) include group and program number in
sudoc2pm.pl
e.g., L ~94
my $group_number = 7;
e.g., L ~108
my $selected_program_name = 'susynvxzcs';
You will need access to the self-instructions of the
seismic unix module, which I find in:
/usr/local/cwp_su_all_48/src/doc/Stripped
run sudoc2pm.pl
uncomment and correctly change
indices,
data types
prefixes,
and suffixes
in the *_spec.pm file
(2) include group and program number in
sudoc2pm_updates.pl
e.g., L ~80-81
my $selected_program_name = 'susynlvfti';
my $group_number = 7;
run sudoc2pm_updates.pl
Confirm that the max_index value in *_spec.pm file is OK and format
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
Q: (NOW DEPRECATED and AUTOMATED-- See immediately above)
How do we add another seismic unix module or seismic unix program to L_SU?
10.06.21 This method is deprecated by using sudoc2pm.pl and sudoc2pm_update.pl
What follows below has been automated largely.
=head2 Instructions
=cut
=head3 In order to create an su module, from this directory,
you will need access to the self-instructions of the
seismic unix module, which I find in:
/usr/local/cwp_su_all_48/src/doc/Stripped
1. modify the following:
sudoc2pm.pl
by adding a line, such as the following:
$file_in[0] = 'xgraph.Xtcwp.main';
2. run the following:
perl sudoc2pm.pl ( under ~L_SU)
=cut
1. modify the following file: sudoc2pm.pl
Add the name of a file and its path, that conatain the help instructions
e.g., $file_in[0] = 'supef.su.main.decon_shaping';
1. Run sudoc2pm.pl
2. Check that sunix notes match the new variables in supef.pm
3. Introduce new variable names at this moment
4. Check supef.config
5. Check supef_spec.pm
6. check supef.pm
7. Move items in 4,5,6 to ~/big_streams/config ~/specs and ~/sunix/ respectively
8. add an appropriate new line in: L_SU_global_constants.pm
For example,
# for seismic unix program options
my @names = ("data_in",
"data_out",
"suximage",
"suxgraph",
"suxwigb",
"sugain",
"suwind",
"supef",
);
9. verify by adding to flow in L_SU
10. when the new module has an internal call for a data set, modify the *_spec.pm file
e.g., for segyread_spec.pm
sub binding_index_aref {
my $self = @_;
my @index;
$index[0] = 8;
$segyread_spec ->{_binding_index_aref} = \@index;
return();
}
sub file_dialog_type_aref {
my $self = @_;
my @type;
$type[0] = $file_dialog_type->{_Data};
$segyread_spec ->{_file_dialog_type_aref} = \@type;
return();
}
11. also modify segyread_.pm by adding a Data Path explicitly
involving a couple of steps:
e.g.
include this call to a library near the start (line 174) of the program
use App::SeismicUnixGui::configs::big_streams::Project_config; AND
my $Project = Project_config->new();
modify a subroutine called file or tape:
use App::SeismicUnixGui::misc::SeismicUnix qw($suffix_segy);
use File::Basename;
my ($DATA_SEISMIC_SEGY) = $Project->DATA_SEISMIC_SEGY();
my $new_file_name = $file;
# deprecated on 10.06.21
# force correct suffix
$new_file_name = basename($file).$suffix_segy;
# print("1. segyread,file, new_file_name= $new_file_name\n");
$segyread->{_tape} = $DATA_SEISMIC_SEGY.'/'.$new_file_name;
$segyread->{_note} = $segyread->{_note}.' tape='.$segyread->{_tape};
$segyread->{_Step} = $segyread->{_Step}.' tape='.$segyread->{_tape};
Q. How do I add a unix program with switches to the module, e.g., evince
Access to the help instructions of the
unix module, which is generated by:
create_evince_doc.pl
1. create_evince_doc.pl does the following:
evince -h > $program[0].par"
You can replace evince by yoor own program name
The o/p is 'evince.par', which contains all the variable/switches you will extract
For evince switches are of the form: --A and --Abc-def
The parser (part 2, following) searches on '--'
2. How do we parse the variable names out"
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
3. via flow_select ( after parsing a perl file via color_flow->perl_parse->_flow_select)
i.e., Only after flow_select_button click changes to Entry widget parameter values will be noticed
4. When the user switches from one program to the next in a flow (flow_select)
i.e. whenever a user selects a program from a list of items in a colored flow ListBox
5. When a user goes to Save the current flow ( just in case the check button has not yet been set to new changes) TODO
6. When a user goes to save the current flow under a name and employs 'SaveAs'
( just in case the check button has not yet been set to new changes) TODO
9-27-2018
What do some of the private variables (hash keys) in spec_files mean?
Normally the spec values were implemented for stdin and stdout.
When the program itself calls files from different directories,
if uses prefixes, and suffixes that are defined internally 7.14.21
Note that if the GUI has 'data_in' as the first program in the flow list
it will be corrected and placed in the bash script into second position
e.g. program < data_file instead of data_file > program
The 'corrected' positions are the ones that are referred to
in the following:
For use internally to program, e.g., when
par-file parameters are bound to a specific directory, such as
a binary file with parameters. This file does not get directed via stdin or stdout
_DATA_DIR_IN input data directory , e.g., $DATA_SEISMIC_BIN for sufctanismod
_DATA_DIR_OUT output data directory
In some situations the key _DATA_DIR_IN can have two or more values within the same program
e.g. sufctanismod:
DATA_SEISMIC_BIN and DATA_SEISMIC_SU
For these cases, the defaulted $prefix (in *_specs nodule) variable will override the key value
at that particular index.
We accomplish this by requiring that the default prefix equal
the value assigned to the key: _DATA_DIR_IN. in the "program"_spec.pm file
But if it is not, the $prefix should be substituted
Also if there is no $prefix, a warning should be issued.
Otherwise,
_DATA_DIR_IN = $prefix value for the index
These changes are considered twice. First, when iFile (_get_DATA_DIR_IN) selects the opening directory
for File_Dialog,
and a second time, when the perl script is being prepared to be written out: oop_prog_params
See oop_
2 previous are used by
iFile,_get_DATA_DIR_IN
iFile,_get_DATA_DIR_OUT
_binding_index_aref unused
_data_type_in data type by suffix
_data_suffix_in exact suffix used for files read by the program
_data_type_out data type by suffix
_data_suffix_out exact suffix used, e..g., '.su instead of only 'su'
: for stdin/stdout and when this program is assembled with others
to form a flow
_file_dialog_type_aref unused
_flow_type_aref unused
_has_infile does it require to read a data set?
_has_pipe_in can linux \|' be used ?
_has_pipe_out can another program follow?
_has_redirect_in can input be a file?
_has_redirect_out can output be a file?
_has_subin_in is binary read in via stdin?
_has_subin_out is binary put out via stdout?
_is_data is this program or a data entry program
_is_first_of_2 in the bash script can this program be the first of two?
e.g., although sugain can be the first of three or more
programs in a flow, it can not be the first of two.
sugain needs at least 3 programs in its flow, one program
brings in data (data_in), another puts data into a file or collects data
from a linux pipe ('|') and sugain is the second of the three programs.
e.g., segyclean, can be the first of two (=true) because data_in and data_out
are not counted...
E.g. suxcor can be the first of two(=tre) because data_in is not counted
If in the GUI listing the user places data_in first and the program_spec says that the program
is able to be first, then the bash script will be corrected
_is_first_of_3or_more ... and can it be the first of three?
_is_first_of_4or_more in the bsdh dvtipy can this program be the first one?
e.g. sugain can be first, but it can also be second
_is_last_of_2 in a bash script can this program be the last one?
e.g. suximage can be the last because it has no output
but sugain can not be last because it outputs a seismic unix file
_is_last_of_3or_more idem. e.g., sugain can not be last because it always produces an output
only display or plotting programs do not outout data to a file or another
program
_is_last_of_4or_more idem
_is_suprog part of the sunix family? Does it follow the same rules for
the purpose of knowing when toplace pipes and >
e.g., evince does follow the same rules
evince does not use a redirect symbol e.g., evince file_name
oop_flows uses this parameter to determine symbols
_is_superflow simple program or a complex of pre-built programs?
_max_index max. no. variables -1
9-28-18
What program sets the directory as a function of the data type (format type) being used? e.g.m
segy, text, su etc.:
iFile
What does iFile.pm or iFile do?
A. iFile.pm->get_Data_path
Q. How does Project Tool update the gui parameter values?
1. When user makes a selection of a new file or folder via bindings
Superflow bindings use the private ('_') subroutine.
Opening a file of folder for a superflow uses _FileDialog_button
FileDialog_button is mainly used for user-built flows but directs superflows
to _FileDialog_button
[ binding to the dialog types for each MB3 click takes place within L_SU
L_SU.pm
pre_built_superflows
# for binding to file dialog options
my $sub_ref = \&_FileDialog_button;
$pre_built_big_stream->set_sub_ref($sub_ref);
$pre_built_big_stream->select();
binding->set (where binding actually takes place) ]
_FileDialog_button
file_dialog
FileDialog_director
# collects the file name or folder and displays it
_pre_built_superflow_close_path
param_widgets4pre_built_streams
redisplay_values();
$L_SU_href = $file_dialog->get_hash_ref();
Also
color_flow
file_dialog
_user_built_flow_close_data_file
get_selected_file_name
2. WHen user selects a new tool
Q. What else does iFile do?
iFile sets the PATHS for data and programs used both in superflow parameters
and in user-built flows.
Q How does iFile get selected?
For superflows:
L_SU
# for binding to file dialog options
my $sub_ref = \&_FileDialog_button;
pre_built_big_stream->select();
For user-built flows
color_flow
FileFialog_button
e.g., when file_dialog_type->{_Data}
file_dialog,
_user_built_flow_open_data_file,
iFile->get_Data_path
or
_user_built_flow_open_path, or
_set_FileDialog2user_built_flow
followed by
iFile->get_Data_path
For superflows:
L_SU,
FileDialog_button,
sub FileDialog_button:
Interactively choose a file name
that will then be entered into the
values of the parameter frame and
stored away via param_flow
FileDialog_director,
_set_FileDialog2pre_built_superflow,
file_dialog,
_pre_built_superflow_open_data_file,
iFile
_pre_built_superflow_open_path,
iFile
_pre_built_superflow_close_data_file,
iFile
_pre_built_superflow_close_path
iFile
get_Data_path,
iFile
get_Path,
iFile
If we are using file_type_dialog = Path
then for a superflow we use file_dialog and iFile and dirs
10-1-2018
What is the sequence of programs for reading a user-built perl flow script file:
e.g., grey_flow,
_perl_flow;
perl_flow
parse
param_sunix
# read in variables from the perl flow file
sunix_pl
get_good_sunix_params
What does binding do?
sets the binding indices and data types BEFORE the programs are employed by any user,
10-1-2018
How does the GUI know which directory to open when MB3 is clicked?
Q. Where does binding take place for parameters of sunix programs within user-built flows
binding, set, reads program_name_spec->binding_index_aref
iFile defines what the directory is to search
indices bound to the right mouse-button click are listed in program_name_spec->binding_index_aref
the input and output directores are defined in the hash 'variable' which can be exported.
Within each program_name_spec.pm file the following subroutines must be populated:
e.g., for suop2_spec.pm: sub binding_index_aref and sub file_dialog_type_aref :
=head2 sub file_dialog_type_aref
The type of dialog (Data, Path, Flow, SaveAs) is needed during MB3 binding
Use one type of dialog for each index
'Flow' will go to PL_SEISMIC by default
'Flow' creates a directory path on the parameter value in GUI (why -- TODO)
'Data' will go to seismic su data by default or
whatever the *_spec file defines the DATA_DIR_IN or DATA_DIR_OUT which could be,
e.g. PL_SEISMIC
'Data' does not create a directory path on the parameter value in GUI (why -- TODO)
'Path' searches for only a directory PATH
SaveAs goes to PL_SEISMIC
_DATA_DIR_IN => $DATA_SEISMIC_SU,
_DATA_DIR_OUT => $PL_SEISMIC,
=cut
sub file_dialog_type_aref {
my $self = @_;
my @type;
$type[0] = $file_dialog_type->{_Data};
$type[1] = $file_dialog_type->{_Data};
$suop2_spec ->{_file_dialog_type_aref} = \@type;
return();
}
=head2 sub binding_index_aref
=cut
sub binding_index_aref {
my $self = @_;
my @index;
$index[0] = 0; # first item is bound to DATA_DIR_IN
# i.e. $file_dialog_type->{_Data}
$index[1] = 1; # second item is bound to DATA_DIR_IN
# i.e. $file_dialog_type->{_Data}
$suop2_spec ->{_binding_index_aref} = \@index;
return();
}
}
Q. Where are _DATA_DIR_IN and DATA_DIR_OUT used?
iFile,_get_DATA_DIR_IN
iFile,_get_DATA_DIR_OUT
Q. What L_SU programs deal with writing the perl flows?
A. Programs that start with "perl" ,
e.g., perl_declare writes the
declaration portion of the flows,
perl_flow creates the flow syntax toward the end of each script
pod_* programs deal with writing perl documentation in perl scripts
Q. What program names deal with writing the perl flows?
A. oop_text directs writing of scripts that are created by the user in the GUI
See oop_text.pm for a list of the programs that are required
Q. What does flows.pm do?
It fixes the order of files in a flow when the user generates a perl script via the GUI.
Q Where are potential errors in the order of the program set when a perl script is written out?
files_LSU,
set_data
flows.pm,
set_specs
set_specs sets the symbols e.g., (>,<,|)
if first program is data_in
switch with the second program in the list that
moves to first location in the flow
Q. Where are symbols , e.g. >,< and | set?
A. In flows,set_specs.
Q. Q. How does a superflow run?:
A. - click Run
within main, _L_SU, sees both a method:save_button, and a deref scalar value:Save
misc::L_SU->set_hash_ref L_SU->run_button
misc::run_button-> director
_Run_pre_built_superflow
explicitly: system("sh $global_libs->{_script}$run_name")
Q. Notes on Syntax 0
Deprecated in April 2018
All flow parameter values should use a beginning and an ending single quote in the following cases:
(a) if a string of text has gaps or symbols such as "(" or "{" or "/"etc.
for example for the variable,
window_title: 'Time (s)' or
a file path: e.g. '/home/login'
if a list of numbers is separated by commas: '2,3,4,5'
(b) unused parameter values can be left empty
(c) some parameter values (Project) require an answer that is an explicit "no" or a formal "yes"
A typical flow starts with the module: "data_in" and ends with an output to a data file by using "data_out"
Q. How does iVelocityAnalysis operate?
After semblance picking,
iWrite_All_iva_out, e.g.,
1. cp /home/gom/Servilleta/seismics/pl/loma_blanca//053018/H/1/gom/ivpicks_'junk'_cdp25 tO
/home/gom/Servilleta/seismics/pl/loma_blanca//053018/H/1/gom/ivpicks_old_'junk'_cdp25;
\
2. cp /home/gom/Servilleta/seismics/pl/loma_blanca//053018/H/1/gom/ivpicks_old_'junk'_cdp25 to
/home/gom/Servilleta/seismics/pl/loma_blanca//053018/H/1/gom/Final_ivpicks_iva_'junk'_cdp25; \
iVrms2Vint,
SUB-STEPS :
1. sort i/p 'ivpicks_old'.'_'.$sufile_in[1].$suffix[3]
o/p ivpicks_old'.'_'.'sorted'.'_'.$sufile_in[1].$suffix[3]
2. convert rms to int
i/p 'ivpicks_old'.'_'.'sorted'
o/p 'ivint_old'.'_'.$sufile_in[1].$suffix[3];
3. generate a data file for plotting
o/p 'plot'.'_'.'ivint_old'.'_'.$sufile_in[1].$suffix[3];
iVA,icp_sorted2oldpicks
iVpicks2par
for user-built flows:
Additional bindings are activated when a flow has more than one program .... at index=0 e.g.. sumute.pl
mutiple flows cause programs parameters to repeat
Q In what sequence are the listboxes filled, starting from a completely empty listboxes?
gray->pink->green->blue
Q In what sequence are the listboxes filled, after all the listboxes are empty?
Only grey listbox wil have its flow sequence completely replaced
Q.Which program keeps track of the listbox currently in use?
Q What is the sequence of modules that are run when an sunix program is called:
param_sunix,
defaults; e.g. in neutral_flow for examples
su_param, get; readfiles,configs
Main
L_SU_sunix_bindings
( e.g., for xk, method=sunix_select, neutral=color, group=shell)
L_SU
user_built_flows
neutral_flow
sunix_select
param_sunix
_defaults
su_param ( sets which global library to use )
developer ( sets the sub-program category)
TODO: is there circularity in what follows?
Q. In how many different ways are configuration files read?
In 2 different ways:
A. For superflows, the sequence is:
Main, _L_SU_superflows calls L_SU->pre_built_superflows (e.g., iVelocityAnalysis.pl)
pre_built_superflow,select calls config_superflows
config_superflows, get_local_or_defaults calls big_streams_param,get
big_streams_param,get extends su_param,get
su_param reads variables using readfiles.pm
readfiles.pm,configs reads in values
Some Superflows do not need visible ticks at the start end end of strings
to run these programs yet.
(todo:readfiles,configs)
B. For user-built flows, the sequence is:
grey_flow;
_perl_flow;
perl_flow, parse();
sunix_pl;
sunix_pl removes the words 'quotemeta'
sunix_pl first removes the ticks at the start and end of strings which also have ticks
sunix_pl then makes sure strings have terminal ticks and numbers do not
For the purpose of saving the correct variables to perl-flows later that used
save values from the param_flows
C. For pre-defined seismic unix program configuration files, e.g. suximage.pm
ultimately, in the same way as superflows:
su_param,get; readfiles,configs;
readflies identifies incoming variables that are strings with string ticks in the sequence,
but removes them as unnecessary. (todo:readfiles,configs )
Q. For superflows, how are configuration files written/saved?
A. For superflows, the sequence is:
main;
L_SU,save_button;
save_button,director,_Save_pre_built_superflow
config_superflows,save;
THEN:
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
my $previous_model = @{ $immodpg_config->{_values_aref} }[14];
my $new_model = @{ $immodpg_config->{_values_aref} }[15];
my $plot_max_t_s = @{ $immodpg_config->{_values_aref} }[16];
my $starting_layer = @{ $immodpg_config->{_values_aref} }[17];
Modify the max index number has to be changed to: (number of variables - 1)
In package: L_SU_global_constants.pm
Change and add new sequence numbers as in array sequences in the package:
array: @superflow_config_names;
e.g., $superflow_config_names[12] = 'immodpg';
That is, change 'temp' to immodpg ( 9 times; lines 25, 42, 61, 25, 82, 98, 114, 130, 146)
and add an additional temp to the arrays and hashes
for the next Tool that will be added
Modify package misc/config_superflows: in two places:
set_program_name ( for the alias)
_set_program_name ( also for the alias)
Also update:
L_SU_path,
$specifications_path_w_slash
$specifications_path_w_colon
Lines 453:
if ( $$program_name_sref eq $superflow_names->{_immodpg} ) {
# warning: must omit underscore
#print("config_superflows, set_program_name,superflow_names=$superflow_names->{_immodpg}\n");
#print("config_superflows, set_program_name,alias superflow_names=$superflow_names->{_immodpg}\n");
$name_sref = \$alias->{immodpg};
}
( I have left a "temp" example you can replace);
Modify the main program, i.e., immodpg.config.pm
so that it can import values from the configuration file
by adding the following lines, as an example for immodpg:
use immodpg_config;
my $immodpg_config = immodpg_config->new();
Also create specs/immodpg_spec.pm for superflows
Update the values in the $immodpg.pm
Also update config_superflows
-> save
Also update program_name definitions
#########################################################################
Q. Inside each spec file, What does binding_index_aref ?
Marks the index of the parameter value,
visible in the GUI, that is bound to MB3
e.g.,
first element in the binding array (= 0)
connects to second item (=1) in the paramter list
$index[0] = 1;
If there is one item that is bound via MB3 to some action,
such as selection of a file or directory, this item
is first in the array and has an index of 0.
Q Inside each spec file, What does file_dialog_type_aref do?
Indentifies the type of binding operation..
which can be of 5 (?) types
The type of dialog (Data, Path, Flow, SaveAs, ) is needed during MB3 binding
Use one type of dialog for each index
'Flow' will go to PL_SEISMIC by default
'Data' will go to seismic su data by default
'Path' searches for only a PATH
'last_dir_in_path' searches for the last directory in PATH
SaveAs goes to PL_SEISMIC
Q. Naming conventions used throughout the programs
$inbound in the variablename means a file and its path are included in the name
$CAPITALIZED_VARIABLES are directory paths always
NADA stands for "nothing significant will happen if this line is commented out"
Q. What are some interesting advanatges of wrapping C code in Perl?
Addtional options can be generated seamlessly. For example, sutaup can have
the range of p's introduced or instead have a range or V's . Input velocity is converted
internally into the range of p's by a method without a need to change the original
sutaup.c Personalization, and extension of functionality can occur while the basic
codes are constant.
Q. How is the Perl formatted?
ALl the code is formatted used Perl Best Practices 2005
using perltidy
Q. where is the output text for the spec files created?
A. developer/sunix_spec
Q. where do I start to look at how perl files are written out?
A. oop_text
Q. What program exemplifeis buinding sepcifications?
A. sufdmod2_spec
Q. If I add a new button, which programs must I update?
Main, L_SU,neutral_flow,conditions_gui,'color'_flow
Q. where is gui history stored:
In gui_history-ref whenever the following modules are used,
The following modules involve gui_interaction
Main
L_SU
color_flow
file_dialog
conditions
run_button
save_button
(decisions? TODO)
pre_built_superflow
Q How to use the spec files for user-built flows and pre-built big streams
NOTE Filedialog uses iFile for opening directories based on second entry label (ps, bin, segy, txt etc)
For bound indices in programs (e.g. curve in suximage, or mpicks in suximage),
FileDialog also uses DATA_DIR_IN from the "spec" files for locating input files = DATA_SEISMIC_TXT
Note that spec-file binding indices is used to determine which indices can have access to FileDialog
Once an index is determined the directory to be opened is in the hash value: _DATA_DIR_OUT
specific directories in the "spec" files are used to build perl files Setups
For example, if file_dialog_type= Data, Data is informed by DATA_DIR_IN and DATA_DIR_OUT
Non-standard uses:
But, file_dialog_type= Data_PL_SEISMIC, is NOT informed by DATA_DIR_IN and DATA_DIR_OUT
$file_dialog_type[0] = 'Data_PL_SEISMIC',
Q. How to add a unix command to the GUI?
e.g. 1.create_evince_doc.pl to create the documentation in a file; o/p is evince.par
2. evince_doc.pm parses out the important switches using regex
3. evince_doc2pm.pl creates the .config, _spec.pm and .pm files
N.B. evince_package, write_pm organizes text sequences for output
Q. Where is_suprog (from_spec file) used?
oop_text
oop_flows
set_specs
Oct. 12: From now on during refactoring:
conditions_gui will try to establish as many of the dynamic defaults
gui_history will try to incorporate user gui responses
Where are flow selection indices highlighted?
In add2flow_button and_add2flow, highlighting occurs
inside gui_history, conditions_gui:
gui_history->set4end_of_add2flow
The index is selected from the previously highlighted part of the flow
Where are the highlight selections recorded?
in delete_from_flow_button and
in flow_select, where the index is recorded before updating prior parameters:
flow_select, gui_history->set_button('flow_select')
Q. In color_flows, how are stored flows updated?
The following use _update_prior_param_flow :
flow_select
The following use _updateNsave_most_recent_param_flow:
_add2flow (used only when reading a perl file)
_perl_flow (used only when reading a perl file)
delete_from_flow_button
add2flow_button
flow_item_down_arrow_button
flow_item_up_arrow_button
In color_flow, the following use: _save_most_recent_param_flow :
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
FileDialog_button: handles Data, SaveAs and (perl) Flow (in) is
main
L_SU
FileDialog_button
_perl_flow
_add2flow
gui_history,set_button (inc index)
flow_select_director('_perl_flow')
_flow_select2save_most_recent_param_flow()
_updateNsave_most_recent_param_flow()
_save_most_recent_param_flow
recorded sequences of indices during an add2flow (3 times), followed by
a deletion (item 3):
most_recent = mr prior=pr index2delete=i update the indices = u ( for flow_select_index_href)
item 1 = index 0; item 2 = index 1;
add2flow: mr -1 pr -2 item=1 ( indices are the same throughout add2flow)
u
add2flow mr 0 pr: -1 item=2
u mr 1 pr: 0
add2flow mr 1 pr: 0 item =3
u m: 2 pr: 1
delete_from_flow_button item =3
mr: 1 pr :2 i: 2
automatically located on item =2
add2flow mr: 2 pr: 1
2/23/2020
Q. How does a selected file name get put inside an Entry box within the gui?
What sequence of programs is used when a data file is selected from within
a parameter Entry box?
For user-built flows as follows:
'color'_flow
_FileDialog_button is used to find files.
_FileDialog_button module lies within each of the 'colored' flows:
e.g. grey_flow.pm, pink_flow.pm, etc.
The type of files that can be opened are
(1) user_built flows {_Flow},
(2) data files e.g. su, binary, par, and plain text files {_Data}, and
(3) pre_built superflows
Q What is developer package?
Hard codes relative location of directories for configuration files, parameter files which are
not accessible via the PERL5LIB global variable or @INC array.
Q. What are the different "flow types" used to bind MB3 clicks
when using the spec files:
{_Data} ... open pre-existing data file
{_Flow} ... open pre-existing user-built flow
{_SaveAs} ... save a new user-built flow
{_Save} ... re-save a user-built flow
{_Data_PL_SEISMIC} ... data file but inside PL_SEISMIC directory
{_Path} ... is a directory
The type of dialog (Data, Path, Flow, SaveAs) is needed during MB3 binding
Use one type of dialog for each index
'Flow' will go only to to PL_SEISMIC
'Flow' creates a directory path on the parameter value in GUI (why -- TODO)
used by:
file_dialog
_user_built_flow_open_perl_file
'Data' will go to seismic su data by default
'Data' does not create a directory path on the parameter value in GUI (why -- TODO)
used by:
file_dialog
_pre_built_superflow_open_data_file
OR
_user_built_flow_open_data_file
goes to $DATA_SEISMIC_SU
'Path' searches for only a directory PATH
In spec files, DATA_DIR_IN and DATA_DIR_OUT define the 'Path'
used by:
file_dialog
_pre_built_superflow_open_path
iFile
get_Data_Path
print("iFile,get_Data_path, DATA_PATH_IN = $DATA_PATH_IN\n");
'Data_PL_SEISMIC" is a general directory path when looking for data inside the
PL_SEISMIC directory
color_flow
_FileDialog_button
file_dialog
_pre_built_superflow_open_data_file
and
iFile
get_Data_path
'SaveAs'
used by:
file_dialog
_user_built_flow_SaveAs_perl_file
Q. What does Project_config do?
A. Defines all the file structure used throughout L_SU by all other packages.
Q. Where are aliases set?
lib/App/SeismicUnixGui/doc/FAQ_SeismicUnixGui view on Meta::CPAN
Q. How are superflow parameters selected in the case of Project
For Project.config there is no local configuration file. This superflow is
handled by project_selector gui or by Project_config itself from within the main L_SU gui.
Q. How are dialogs provided to the user?
Q. How are error messages conveyed to the user?
As an example, look at
L_SU L 402
$color_listbox->my_dialogs( 'color_listbox', 0 )
Two possible outcomes ($ans4ok and $ans4cancel)
The first parameter called is the title of the dialog box and the
second parameter (this case = 0) selects which message to display.
The first parameter also serves to find the corresponding message which
can be found within the messages folder
Q.. How do I know that a listbox is about to be overwritten?
color_listbox
my $vacancy = $color_listbox->is_vacant_listbox($future_color);
Q. What is gui_history used for?
gui_history is a hash and module of the same name that stores common variables that are needed by multiple
programs at once.
e.g., within conditions4flows we have:
conditions4flows->{_occupied_listbox_aref}
The hash variable:
"_occupied_listbox_aref ", accessible in
L_SU via the shared "gui_history" hash
Q. Where do we set vacancy and occupancy of 'color' listboxes?
In color_flow:
delete_from_flow_button
In L_SU:
user_built_flows and FileDialog_button
conditions4flows, set_defaults4delete_whole_flow_button
gui_history
conditions4big_streams
conditions_gui (deprecated? Should be! 7.15.21)
Q. Which module keeps track of which colored listbox is occupied?
L_SU, color_listbox
Q. Where do we check to see whether a flow box is occupied before we can reserve a space?
Q. What are the extension abbreviations for different types of files, according to their format
text is usually txt
SEG-Y files is usually sgy
Seismic Unix files is always su
binary files bin
Extra: "no extension" means go to the PL_SEISMIC directory to search for or deposit files
Q. How does L_SU know on which line to put a selected file name in the parameter list?
(1) _spec files bind the index of the appropriate line in the list to a directory which will be openened.
TODO: A click in the first line always will take the user to a data directory
TODO: make ALL links via bindings
defined in *_spec files.
(2)
Q. How do I add another default directory to be created when a new project is saved and run?
For examples a new directory call 'png' for image files of that type?
Follow the examples:
in: ~/configs/big_streams/Project_config.pm where all used and unused definitions are kept
and in in ~big_streams/SetProject.pl where we can see how some are implemented but others are
not (Commented lines)
Q. How do I add in a new sunix-based program into L_SU, e.g., a
Seismic Unix program such as sufctanismod
EXAMPLE 1
1. Run ~ developer/sunix/sudoc2pm.pl
As a result, three files will be generated:
A. sufctanismod_spec.pm,
B. sufctanismod.config and
C. sufctanismod.pm,
These three files are found in the same directory as their model
program
e.g.~ developer/Stripped/model
2. Modify each file as follows:
A. sufctanismod.config
Make sure that only variables and their values that belong to the program appear in
this file. You will have to carefully review the self-documents that correspond
to this program, i.e. ~ developer/Stripped/model/sufctanismod.su.main.synthetics_waveforms_testpatterns
B. sufctanismod.pm
Make sure that you have one method/subroutine for each of the variables listed on one line each
in 'sufctanismod.config'. Because there are 61 such variables in this example, make the $max_index =
(number of variables -1 ) = 60
Near ~ L1824 ...
my $max_index = 60;
C. sufctanismod_spec.pm
Although tis program is used in standalone fashion normally, for convenience,
I kept all the default settings that explain the behavior of this program for stdin and stdout.
3. Move each of the 3 files into their respective directories:
A. Move sufctanismod.config to ~configs/model
B. Move sufctanismod.pm to ~sunix/model
C. Move sufctanismod_spec.pm to ~specs/model
4. Modify the following perl modules:
A. ~misc/L_SU_global_constants.pm
~ L. 442
In alphabetical order, include the program name within the following list :
my @sunix_model_programs = ( "suplane", "susynlv", "unif2", "suea2df", "sufctanismod","sufdmod1", "sufdmod2" );
EXAMPLE 2
1. Run ~ developer/sunix/sudoc2pm.pl
As a result, three files will be generated:
A. vel2stiff_spec.pm,
B. vel2stiff.config and
C. vel2stiff.pm,
These three files are found in the same directory as their model
program
e.g.~ developer/Stripped/par
2. Modify each file as follows:
A. vel2stiff.config
Make sure that only variables and their values that belong to the program appear in
this file. You will have to carefully review the self-documents that correspond
to this program, i.e. ~ developer/Stripped/par/vel2stiff.par.main
B. vel2stiff.pm
Make sure that you have one method/subroutine for each of the variables listed on one line each
in 'vel2stiff.config'. Because there are 18 such variables in this example, make the $max_index =
(number of variables -1 ) = 17
Near ~ L618 ...
my $max_index = 17;
C. vel2stiff_spec.pm
This program is used in standalone fashion normally, for convenience,
I kept most of the default settings that explain the behavior of this program for stdin and stdout.
L~24
my $max_index = 17;
However, I did change the 'values' of the following 'keys':
~L28-29
_DATA_DIR_IN => $DATA_SEISMIC_BIN,
_DATA_DIR_OUT => $DATA_SEISMIC
~L31-34
_suffix_type_in => $bin,
_data_suffix_in => $suffix_bin,
_suffix_type_out => $bin,
_data_suffix_out => $suffix_bin,
I also had to ALSO import new variables into the module:
~ L 6
use App::SeismicUnixGui::misc::SeismicUnix qw($su $suffix_su $bin $suffix_bin);
~L 21
my $DATA_SEISMIC_BIN= $Project->DATA_SEISMIC_BIN(); # output data directory
In the GUI for vel2stiff, there are many files (14) that have to be defined
by the user (using MB3). The MB3 callback are programmed as bindings.
Bindings are named within this same module (vel2stiff_specs.pm) for each
of the 14 files, in a method/subroutine:
sub binding_index_aref
e.g., ~L77:
$index[10] = 10; # second item is bound to DATA_DIR_IN
We also need to know for the purpose of the widget that allows the user to select
or name the file that the files to be opened contain "Data"
sub file_dialog_type_aref
e.g., ~L110:
$type[10] = $file_dialog_type->{_Data};
The current seismic unix program forms part of a work-flow
that is being built by the user. For this last reason the method/subroutine:
sub flow_type_aref includes a "flow_type" name for each file, e.g.,
e.g., ~ L141
$type[10] = $flow_type->{_user_built};
3. Move each of the 3 files into their respective directories:
A. Move vel2stiff.config to ~configs/par
B. Move vel2stiff.pm to ~sunix/par
C. Move vel2stiff_spec.pm to ~specs/par
4. Modify the following perl modules:
A. ~misc/L_SU_global_constants.pm
~ L. 442
In alphabetical order, include the program name within the following list :
my @sunix_par_programs = ( "suplane", "susynlv", "unif2", "suea2df", "sufctanismod","sufdmod1", "sufdmod2" );
Q. What happens if I just default type[0] to nothing, an empty string?
A. $type[0] =''; Is it a local text file?
Q. What happens if I just default binding to $index[0]?
A. TODO
For bindings in the *_spec files
The values within the @index array do not need to bear the same
number as the index sequence itself, e.g.
$index[22] = 24;
$index[40] = 61;
Q. Where does binding take place for parameters of sunix programs within user-built flows
binding, set, reads program_name_spec->binding_index_aref
iFile defines what the directory is to search
Q. How are output file names selected when writing user-built scripts?
files_LSU
color_flow
FileDialog
file_dialog, get_perl_flow_name_in();
save_button
files_LSU, set2pl
$files_LSU->{_flow_name_out} = $hash_ref->{_flow_name_out};
_set_outbound2pl
$files_LSU->{_flow_name_out}
files_LSU,save
Q. How do I read a configuration file for a Tool that is not Project, e.g. iPick
iPick
iPick.pl
iPick_config
get_values
config_superflows
get_values
_local_or_defaults
big_streams_param (extends su_param)
get
_check4local_config
via Module::Refresher
iPick_spec
uses Project_config->PL_SEISMIC
Q. How are directories found? 9-4-21
A1. For user-built flows:
By using *_spec files
CASE A:. There is a "back-door" default definition that the first parameter values (index=0)
always searches for the default
value of _DATA_DIR_IN
CASE B: For stdin and stdout also use only _DATA_DIR_IN and _DATA_DIR_OUT
CASE C: For additional directories when there are "internal" files required by the programs,
override directory names using $prefix values which are found in _spec files.
Note: flow_type from the *_spec files is not being used in L_SU ... TODO... ??
TODO: oop_declare_data_out and oop_declare_data_in have a lot of unneeded subs?
A2.For pre-built super flows
If there are superflow bindings for opening data files, then these use
L_SU, pre_built_superflows,
pre_built_big_stream->select( )
_FileDialog_button,
pre_built_superflow,select,binding->set() (where actual binding takes place!)
_pre_built_superflow_open_data_file uses iFile->get_data_path is used to determine the correct data path (directory)
[ binding to the dialog types for each MB3 click takes place within:
L_SU
pre_built_superflows
# for binding to file dialog options
my $sub_ref = \&_FileDialog_button;
$pre_built_big_stream->set_sub_ref($sub_ref);
$pre_built_big_stream->select();
binding->set (where binding actually takes place) ]
sumedian filter for VSP (filters)
sueipol- eignevalue based polar filter (filters)
pahse inversion deconvolution
Q. How does project-selector run in general terms"?
L_SU_project_selector.pl
(program name is defined as 'Project')
project_selector
->set_current program
L_SU_local_user_constants
get_active_project_name
_get_local_or_defaults
big_streams_param
get
Q How do you deal with redefined subroutines:
A.1
Both of the following instantiate iPick_spec.pm
--iPick_config
calls
config_superflows
calls
big_streams_param
which requires and instantiates iPick_spec
--iPick.pm
uses and instantiates iPick_specB.pm
uses iShowNselect_picks
which instantiates iPick_specC
uses iSelect_xt
which instantiates iPick_specD
A.2 Similarly for :
grey_flow, green_flow, pink_flow, blue_flow
param_widgets_neutral, param_widgets_pink,
param_widgets_green, param_widgets_blue,
param_widgets_grey
param_flow_grey, param_flow_green,
param_flow_blue, param_flow_pink
A.3 By removing the 'aliased' option
Q. How do I automatically locate the directory for a specific module, selected by the user, e.g. ctrlstrip?
Can you provide an example?
A. Yes, when the user selects
ctrlstrip, the "program group name" is "data" and all the "data" modules
will be found in $SeismicUnixGui/sunix/data
e.g., $SeismicUnixGui/sunix/data/ctrlstrip.pm
This is possible because for any Seismic Unix program selected,
the following sequence of instructions are enacted:
in main
_L_SU_sunix_bindings, which
stores group name, e.g., data or transform or migration, etc.
$gui_history->set_sunix_prog_group($prog_group);
stores which colored flow chart is being selected:
$gui_history->set_sunix_prog_group_color($color);
stores which button is being selected. The "$button"
will have either a value of "sunix_select" if MB1 is clicked
or "get_help" if MB3 is clicked.
$gui_history->set_button($button);
provides all the gui information to the module L_SU in a hash
$L_SU->set_hash_ref($main_href);
provides user-built-flows the type of method being used, e.g. is it
just a selection (MB1) of a program or we looking for help (MB3) on this module
$L_SU->user_built_flows($method);
e.g.,
$sunix_data_programs_listbox->bind(
'<3>' => [ \&_L_SU_sunix_bindings, 'get_help', 'neutral', 'data' ] #TODO return to 'neutral'
);
Q. How is the help accessed, i.e. reading the program comments written in the
pod markup language, within a module?
A. Following on from the previous questions, if MB3 selected,
L_SU
user_built_flows
neutral_flow->get_help
help
tkpod
Q. hHw can get-hlep find the correct path for a particular module?
gui_history stores a lot of useful information on the user's click history,
and can be accessed to find out what the user has just done. This
method contradicts a lot of the pure object-oriented coding but speeds
up the process tremendously. I am thinking of implementing this throughout
to speed up the gui in a lot of weak spots. 9-19-22 JML
Q. What happens when you 'Save' after having Opened a file
To 'Open'
main
L_SU
color_flow
FileDialog_button
file_dialog
FileDialog_director
_perl_flow
_add2flow
_flow_select_director
(widget any color_flow_href values are all present and
displayed on the GUI)
_flow_select2save_most_recent_param_flow(
To 'Save'
main
L_SU
color_flow
save_button
param_widgets_color->redisplay
Q. Where are dynamic variables kept in memory for each flow?
For example, the program parameter values are kept in 3 places
color_href
param_widget
param_widgets only keep a copy of what was last seen on the screen
When we open a new sunix program, the param_widgets are updated
But if we reselect an open color flow the param_widgets
are reoccupied by what was stored in color_href. In this manner we
can minimize memory usage for param_widgets
Q. When I select a superflow or big stream, what are some of the subs are used?
L_SU.pm
pre_built_superflows
# for binding to file dialog options
my $sub_ref = \&_FileDialog_button;
$pre_built_big_stream->set_sub_ref($sub_ref);
$pre_built_big_stream->select();
Q. What do the different names in superflows/Tools/pre-built flows/big streams mean?
While using L_SU_global_constants.pm:
CASE of $alias_superflow_names_h, (used by sub alias_superflow_names_h),
and $alias_superflow_spec_names_h (used by sub alias_superflow_spec_names_h)
The names seen in the gui do not have to be the same as
the internal program names.
For example 'fk' for the user of the gui
is the same as Sudipfilt
internally for the programmer.
CASE of @superflow_names_gui, (used by superflow_names_gui_aref),
@superflow_names (used by sub superflow_names_aref),
Are as seen differently in the GUI
e.g., fk
CASE of @superflow_config_names (used by sub superflow_config_names_aref),
Are the internal names for configuration files,
e.g., Sudipfilt_config
unclear CASE ...
$superflow_names_h (used by sub superflow_names_h)
because both fk and Sudipfilt are included her
Try to keep the use of only internal names within the program, and not the aliased version
#####################################################
TODO
Deprecation TODO: July 2024
replace $name with $program_name
and consoidate program name definitions into L_SU_global_constants or equivalent
Currently progam_name has definitions that are repeated in L_SU_global_constants
Not working??
project_selector->_get_labels_from_gui
But, this is working!
project_selector->_get_labels_from_gui
When creating the first project using SUG, two configuration
files appear in .L_SU/configuration/"Projectname", i.e. Project.config and "Projectname.config"
Can not understand ??
( run in 0.533 second using v1.01-cache-2.11-cpan-2398b32b56e )