wiki:tfit

TFIT has been superseded

Please see its successor package T-PHOT (Merlin et al, 2015)


TFIT is presently inactive. This page serves as a collection of final thoughts and things we would like to fix someday if we have the time and resources.

The main strand of development is on the trunk. All released versions were tagged with the release name and date; they can be found in the tags directory. In general this should be considered a readonly portion of the repository; all changes should be made on the trunk. No TFIT branches were ever made.

A Developer's Guide has been added to the doc/ directory. It describes the organization of the code, and briefly describes each file. There's also a brief guide to TfitDeveloperTools.

All python code is in the lib/ directory, including all the standalone utility scripts. Note that TFIT has its own copy of sextutils. Automatically-generated API documentation that may be of interest to developers, but will certainly not be of interest to users, is available for browsing.

C++ code is in the src/ directory. A make command is issued from within the setup.py to build the C++ executable as part of the package installation; it can also be issued manually in development.

There is one configured test suite for TFIT, located in the test/ directory, but it is rather weak. See the test/README.txt file for more details.

The release notes in the docs/ directory summarize the changes associated with each formal release. More detailed change information can be obtained from the revision log via the Trac site.

Code to run simulations is in the puresim/ directory, but I don't recall whether or not it was left in a working state. (At one point we had considered, and begun, an ambitious redesign of the simulation code which we had to abandon before completion due to lack of resources, but I don't think that's what this is.) It looks like it was written to work with the new (v1.0) user interface (ie, unified parameter file, stages of pipeline, etc), so that's promising.

In the final stage of the project, a number of tickets were closed because they were out of scope.

Here is the list of those tickets. We had also discussed:

  • Removing PyRAF dependencies from the core pipeline by rewriting the cutout stage in pure Python. It presently uses the IRAF task imcopy, mainly for its built-in handling of the WCS details. If and when the imutil package is rewritten in pure Python, as has been discussed by SSB, this would become trivial.
  • Removing PyRAF dependencies from the dance-related stages, which use imlintran and xregister. This is probably further out of scope.
  • Moving to some kind of iterative approach instead of the dance. This would be hard & require working inside the C++ where the fitting is done
  • Special handling of objects that are saturated in the HR image: eg, use the kernel as a template, to avoid propagating artifacts from the HR image into the template. This would be tricky because of position and bounding information: not hard, just a lot of bookkeeping to make sure you get right.
  • Modifying what happens when just a few pixels of a template are flagged out. In theory, we could simply mask out the flagged-out pixels from the fit. In practice, this is tricky because the mask-construction logic inside the fitter (C++ code) is far away from the flag-checking logic, and is a bit tricky itself. Everything outside the fitter works in object/template granularity, not pixel-level granularity. It's also not clear how to decide when to accept the template and just mask the relevant pixels, vs when so much of the template is flagged unusable that the whole thing should not be used.
  • Getting smarter about the use of the covariance matrix to generate meaningful contributions to the flux errors. This probably requires some real statistical mojo.

Previous releases

Last modified 4 years ago Last modified on 05/22/15 16:15:50