tlittenberg / ldasoft Goto Github PK

In order to extract point estimates of the global fit model the sampler needs a global index

Along with producing run.sh, gb_mcmc should automatically produce example script for calling gb_catalog

Something is wrong with the dOmega calculation in Fisher Galaxy, because results are not always positive!

Tyson, here is your reminder to create path/to/data/waveform.dat

command line argument to not do the GMM fit in the gbmcmc post processing (costly and not always needed)

residual output should only be over analysis window and not include buffer. that means residual production should screen out samples w/ q < qmin+qpad etc.

the title says it all

Hi, I am interested in doing parameter estimation for LISA and came across your amazing package. I tried the test run and have some question regarding the order of input (and output) parameters "cos_colat" and "long".

I used command:
gb_mcmc --inj somepath/ldasoft/gbmcmc/etc/sources/verification/AMCVn.dat --em-prior somepath/ldasoft/gbmcmc/etc/sources/verification/AMCVn_prior.dat --known-source --no-rj --cheat --samples 128 --fix-freq and then bash example_gb_catalog.sh 1 to analyse the results.

The sky location (cos-colat,long) appears in all of the files, but the definitions seem inconsistent.
The parameter file is:
> cat AMCVn.dat
#f(Hz) | fdot(Hz/s) | costheta | phi(rad) | m1 (msun) | m2 (msun) | cosinc | d (kpc)
0.001944144722 0 0.6080 2.9737 0.68 0.125 0.7314 0.302
But the parameter estimation result suggests the other way around:
> cat catalog_1/LDC0019441447_params.dat
0.001944144722 -2.01116740697e-18 2.83244402359e-22 2.9737 0.608 0.713865768392 0.249565325314 0.272174439929
According to the documentation, the data in catalog_N/LDCFFFFFFFFFF_params.dat are:
f | fdot | A | cos_colat | long | cos_inc | psi | phi

By comparing the number, it seems that (spreadsheet refers to link)

• cos(co-latitude)[in spreadsheet]=costheta[in AMCVn.dat]=0.6080=long[in LDC*params.dat]

• longitude[in spreadsheet]=phi(rad)[in AMCVn.dat]=2.9737=cos_colat[in LDC*params.dat]

GalacticBinarySimulateData() is empty, need to strip out simulation steps in injection codes.

In apps/src/CMakeLists.txt, move all target_link_libraries(...... glass_utils) lines just before just before each "install(TARGETS ...)" line.

Some linkers (apparently the ones on Linux, but not on OSX) require a particular order for the libs: The library providing a symbol must always come after the library that needs the symbol.

Upon running the following command, the output of GBMCMC has two parameters (I believe they are phi and costheta) which do not change at all throughout the analysis. Additionally, there are two other parameters (I believe psi and phi0) that alternate roughly between two values and do not mix well.

The command I used to create this:
~/ldasoft/master/bin/gb_mcmc --inj ~/ldasoft/gbmcmc/etc/sources/verification/ZTFJ1539.dat --known-source --no-rj --duration 31457280 --cheat --samples 32 --step 10000

I am not sure which version last worked, but one that I know works is this commit: f5ba624

Working on gbFisher, it seems that all of the lda-soft software is apparently interlinked (e.g. gbFisher requires code files listed in other source directories of lda-soft)

Dependency issues aside (that architecture should be thought about carefully) I recommend updates to the documentation to include:

(1) instructions that clearly define the installation of lda-soft, which says you need to build the entire repository

(2) Instructions should also clearly indicate package dependencies (e.g. gsl, version, etc)

(3) In the individual documentations (e.g. for gbFisher) it should say at the top what you need to do to make the code. I tried to use the gbFisher makefile and it wigged out because it couldn't find the dependent file -- the point is you can't use the makefile as included in the src repository, so the documentation should be clear on that point

(3) I think it would be useful, if the architectural dependencies could be resolved, to only be able to use one part of lda-soft (e.g. gbFisher, without any intent of every using gbmcmc)

Currently each proposal can have a unique protocol for evaluating the density.
This should be standardized, and pointers to the density functions should be included in the proposal structure, to make it easier to insert new proposal functions

• more samples (for nicer post processing)
• fix normalization (for easy-to-interpret evidence)
• fix SNR

This needs to be consistent with the data. You shouldn't need to specify a potentially inconsistent value.

~/gb_mcmc -h

starts running something, which it shouldn't do.

~/gb_mcmc --help invokes `help' correctly

The example in the help doesn't work:
./gb_mcmc --orbit ../config/OrbitConfig1.txt --verbose --inj ../data/sources/RXJ0806.dat

samples are not always being written to GW<>_chain.dat properly.
Some catalog entries have only one unique set of parameters repeated for entire length of file.