column names hardcoded in fault modeler

This issue pertains to work in progress on the fault modeler, in the 'fault_conversion_utils' branch that has not yet been merged into master.

@klunk386 @julgp @mmpagani please review:

The primary problem is that non-default geojson column names are being hardcoded into the fault_source_modeler.py script, in the param_map dictionary[^1].

The new library was written so that project-specific settings that are not default (things such as column/attribute names) are not hardcoded in, but are specified in a project configuration file. This was done because attribute names can and will change between projects. There is no reason to force everyone who uses this library to have a specific set of attribute names, or to prevent us from changing the names as the fault database project evolves.

By hardcoding these values in the fault_source_modeler.py script, this repeats the old problem with brittle code, after I re-wrote the library to fix this problem. I don't understand why it is necessary or desirable.

As a side note:
My opinion is that the fault_source_modeler.py should take as its primary argument a project configuration (.ini) file, that contains all non-default parameters (not only column/attribute names, but any non-default parameters including scaling relationships, seismogenic depths, rupture mesh spacings, temporal occurrence models, or anything else. The GIS input and XML output files would also be specified here. This prevents all of these parameters from having to be a) hardcoded into the fault modeler each time, or b) having to be passed as command line arguments each time. It is very hard to keep track of all of these parameters, especially ones only passed on the command line, because you have to search through your bash history to find out what you did. Good luck with that after a few months or a few years! Also, version control can be used so that the parameters are tracked with the output file. This is impossible with the current system.

Also, It is no more work (it is less work, in fact) to write them once into a .ini file than pass them on the command line.

An example .ini file is below

[config]
fault_gis_file = ./ne_asia_faults_rates.geojson
outfile = ne_asia_fault_model.xml

[param_map]
average_dip = ns_average_dip
name = ns_name
strike_slip_rate = ns_strike_slip_rate

[defaults]
rupture_mesh_spacing = 0.5
lower_seismogenic_depth = 15
name = 'no_name'

Then, the fault_source_modeler.py file reads this file and does all of the necessary work based on the parameters here. I have provided a preliminary working version of this script to @klunk386 and @julgp as an example.

Then, the XML file is built with fault_source_modeler.py config.ini instead of passing all of the arguments as command line arguments. I know this is different than was done in the past but it seems to me to be simpler.

Just to be clear, Values only need to be written for non-default parameters, not for all of the parameters needed for a project other than the input gis file name.

If we want to discuss this further (and we should, as a group, come to a decision) I can make a separate issue for this topic.

[^1]: These column names are found in the early versions of the fault database, and are inherited from the old Faulted Earth project. They are not used in the current Global Active Faults database and are not in the current CCARA faults, for example. However, because the old scripts used to make the .xml files were brittle and had these values hardcoded, I did not update those column names in the geojson files we were using for hazard modeling because this would break the scripts. However, these column names have been simplified to make them less confusing.

Start by reviewing the work in progress on the fault_conversion_utils branch and the fault_source_modeler.py script, especially its param_map dictionary. Compare the proposed config.ini structure with the script's current inputs and determine the agreed scope for moving non-default parameters into configuration. Done means the hardcoded column names and selected project parameters are driven by the configuration approach accepted by the project.