[CIG-SHORT] Adding to the libraries

[Ehsan Haghighat]

Hi Brad,

Thanks for the reply. There is a code developed here at our group, and I am trying to refactor that. It has developed in Pylith 2.1.0. So, it needs a lot of changes before bering able to merge it with current development. 

About the previous question, I was trying to find out how the automake and swig are being called, and adding a material was the easiest way to check it out. So, I think I now know the limitations of the released version versus the developer version. I was able to use the added material with both released and git-master versions. For now, I do not have any further questions.

Thanks for your support, it was indeed very helpful. I will keep in touch in case I had questions.

Best regards,
Ehsan



> On Aug 6, 2017, at 3:20 PM, Brad Aagaard <baagaard at usgs.gov> wrote:
> 
> Let's take a step back and start from the beginning... you want to add a material model to PyLith. Therefore, you need to work with an installation that supports developing/extending PyLith. There are multiple ways to do this:
> 
> 1. Use the v2.2.0 (or later) binary package.
> 
>  The binary package includes the compilers and SWIG, so you have the necessary tools. Instead of rebuilding PyLith, in this case you would follow the templates/materials example, not touching the main source tree at all.
> 
>  The disadvantage of this approach is that you cannot easily stay updated with PyLith fixes. You have to download a new binary tarball and rebuild your extension with each new release.
> 
> 2. Install from source using the installer and the --with-pylith-bit=BRANCH. Configuring the installer with these options insures it builds the necessary tools (e.g., SWIG).
> 
>  a. Use the PyLith master branch. This is the stable development version. If you have any intention of keeping in sync with PyLith development, this is the preferred option. You can easily merge in updates/fixes we do and keep in sync going forward. We do our best not to fix all bugs before merging features into the PyLith master branch.
> 
>  With this approach the installer will also use the PETSc repository (knepley/pylith branch) and the spatialdata master branch. We are constantly making sure these three stay in sync.
> 
>  b. Use a previous tagged version of PyLith and rollback PETSc to the corresponding commit. As Matt said this is most easily done using the date. You can also download the binary and run pylith --version to find the PETSc commit corresponding to that PyLith release.
> 
>  I am not sure why you would want to use a previous tagged version rather than the stable development version.
> 
> 3. Install from source using the installer to build the dependencies, but use your own fork of the PyLith repository.
> 
>  In github, you would fork the PyLith repository and clone it to your local machine and build PyLith. You would still want to make sure you use PETSc and spatialdata from the repository with the installer.
> 
> IMPORTANT NOTE: With option 2 or 3, I still **STRONGLY URGE** you to follow the example in templates/materials to add a material. PyLith is designed so that you can build a simple extension rather than working with the main source tree! This approach is much easier to debug as it only involves your new files.
> 
> If you have questions, please explain what your goal is and outline how you plan to get there. It is much easier to steer you down the right path if we know what your end goal is than respond to specific questions that may be a result of heading down the wrong path.
> 
> Regards,
> Brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20170807/4a0675b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1846 bytes
Desc: not available
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20170807/4a0675b6/attachment-0001.bin>