-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try to include invlib in linemixing #281
Conversation
@simonpf Thank you! I have some questions because I have been unable to use the minimization-routines even though it now compiles. In python, I can write the following: from numpy import array, mean
import scipy as sp
import scipy.optimize
T = array([200., 205., 210., 215., 220., 225., 230., 235., 240., 245., 250., 255., 260., 265., 270., 275., 280., 285., 290., 295., 300., 305., 310., 315., 320., 325., 330., 335., 340., 345., 350.])
Y = array([-3.01073e-06, -3.11330e-06, -3.21125e-06, -3.30471e-06, -3.39379e-06, -3.47865e-06, -3.55942e-06, -3.63624e-06, -3.70925e-06, -3.77860e-06, -3.84440e-06, -3.90681e-06, -3.96596e-06, -4.02197e-06, -4.07498e-06, -4.12510e-06, -4.17245e-06, -4.21715e-06, -4.25932e-06, -4.29905e-06, -4.33645e-06, -4.37162e-06, -4.40466e-06, -4.43566e-06, -4.46471e-06, -4.49189e-06, -4.51729e-06, -4.54097e-06, -4.56303e-06, -4.58353e-06, -4.60253e-06])
def T4(T, X0, X1, X2):
T0 = 296.0
G = T0 / T
return (X0 + X1 * (G - 1)) * G**X2
x, cov = sp.optimize.curve_fit(T4, T, Y, [mean(Y), -mean(Y)*1e-2, -0.75]) This will yield me a decent approximation of the best-fit. Now using your code, I am supposed to call template<typename Real, typename Vector, typename CostFunction, typename Minimizer>
int minimize( CostFunction &J,
Minimizer &M,
const Vector &x0,
Vector &xi,
unsigned int max_iter,
Real tol ) as far as I can see. My short question is: How do I call this so that it is similar to the python case above? So far, I have tried the following things:
I can get the gradient descent |
@olemke This now updates Eigen. I didn't find any issues with the update other than several new long to int compiler warnings. Since I want to use an "unsupported" module, I also had to add some new files (prompting the update of version because I don't want them from different versions). I changed the layout of the Eigen folder so that the "unsupported" module is separated from the supported module on a folder level. Is this OK? I also attach a working version of a cminpack "port" that I first implemented before finding Eigen had the fits. I think there were a few interface changes I had to do to get it working with Eigen, but I prefer the Eigen code because it is readable. I attach the cminpack-code anyways since it worked with pure matpack types in case there is a good reason to not use Eigen unsupported here. I prefer the Eigen interface. |
I'm all for sticking with Eigen. I see two different warning behaviours with the updated Eigen. As you mentioned GCC warns about the conversions. With Clang, I get lots of warnings inside Eigen where enum values are shadowed within the same class.
|
@olemke Is there really no way to just say that some files should ignore those warnings? Otherwise I will remove them. |
You can put this pragma boilerplate around the places where Eigen gets included in ARTS: #pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow"
#pragma GCC diagnostic ignored "-Wconversion"
#pragma GCC diagnostic ignored "-Wfloat-conversion"
#include <Eigen/Dense>
#pragma GCC diagnostic pop This will also fix the warnings in Clang. |
94d1419
to
2620f42
Compare
@olemke I went with the warnings removal. I also added similar tricks in CMake for the imgui and wigner libraries to remove their warnings (using PRIVATE, which I think means the compilation options are not forwarded). |
This can be merged if all checks pass. Merging this closes #282. Even if I did not end up using Merging this also closes #136 . The latter is more controversial to close because we are not getting exactly the same results as the original paper. However, what we get is reasonable and it should just be a matter of finding minor differences now. When the issue was opened, the results were vastly different. Now, there is at least one instrument that would benefit from merging this code (TEMPERA) as it would be the only way for them to combine low altitude/high pressure line mixing and high altitude/low pressure Zeeman effect. To see the outputs here, it is possible to look at Note: Merging this should open a new issue for anyone that is mathematically inclined. The constructor of |
…line definitions.
Also add curve_fit similar to python scipy.optimize.curve_fit but with a little bit different interface This addition required adding the unsupported/ modules of Eigen if this is not desired, I have a port of the underlying MinPack code that accepts a mostly similar interface. I prefer using the Eigen interface since it is possible to read and understand instead of relying heavily on pointers inside lapack/blas functions I cannot figure out how to use invlib for the task of minimizing these things, and it seems to not be too important to do so since the resulting output is actually not very easy to use (the Rosenkranz paramters don't seem to actually work very well when coming from ECS). Still, the method to confirm that is tedious without this code, so the code must be available somehow...
These just makes the type easier to deduce for the compiler removing a lot of compiler complaints from some code that I was writing while debugging the line mixing. It also renames some of the conversions to be named explicitly after what they do (no longer "hitran 2 arts" but "kaycm 2 hz") since there are plenty of non-hitran uses of these conversions For some unknown reason, this also changes slightly the output of one of the tests that rely heavily on these conversions, but it did not seem critical enough to change since the new output should be at least as good as the old
using GCC pragmas Also began adding Jacobian calculations to the ECS linemixing module as it has to be done via perturbations before I figure out how to do a derivative of a Eigenvalue system...
Note that this requires perturbations because otherwise it will not work. The main problem is I do not know how to compute derivatives reliable of the constructor of EquivalentLines
web-browser for Doxygen. This option is recommended for two reasons: 1) Use this if you do not have LaTeX installed; or 2) Use this if you want to formulas look prettier in the HTML output Using old method, PNGs were generated with all the formulae in the doxygen comments ("\f[ ... \f]" for outline, and "\f$ ... \f$" for inline formulae). I hope this works because the old method generates a whole lot of very long and cumbersome error output...
7aae707
to
c72b751
Compare
@olemke This branch is now up-to-date with the recent merges. It can be merged. The caveats here are:
The advantages are:
|
Putting it in Github would at least make sure that it's not completely lost. A comment/FIXME about the problem in the code could also helpful. |
-Wno-format-overflow is GCC-specific and triggers an 'unknown warning' warning in Clang. It is now only added for GCC. Merge target properties for disotest and cdisort into one statement.
I'll add a comment in the code. I'll also add a github issue when it is merged. I will mark the issue with what combination of tags? I will put these two "enhancement" and "help wanted" for now. |
Unmerge targets because only disotest needs ENABLE_ORIGINAL_OUTPUT_HANDLING
Yes, those two fit. |
Very nice. The MathML formulas look really good and should nowadays be supported by all modern browsers. |
This is code that should not be merged before the linker error is fixed and the actual best-fits are done well.
@simonpf
I am trying here to include your optimizations.h. It creates linker issues because of the inclusion of the C++ files in the headers, as you noted in our email-exchange.
I want to use this style of minimization to mimic python
curve_fit
so ARTS can compute the line mixing parameters Rosenkranz coefficients by itself from data. The examples are in linemixing.cc'slinemixing_ecs_rosenkranz_adaptation
. This is one of several best-fits that I would like to attempt. The specific ones for now are:DPL:
![DPL](https://camo.githubusercontent.com/5c9cb8366de06dbf491bbd307acb2d6390abe22a2da342960cb61e222d5c1cc1/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f7376672e6c617465783f5c4c617267652673706163653b582854293d585f305c6c656674285c667261637b545f307d7b547d5c7269676874295e7b585f317d2b585f325c6c656674285c667261637b545f307d7b547d5c7269676874295e7b585f337d)
T4:
![T4](https://camo.githubusercontent.com/0922e8ddcd3da0cc4119e499be3f2a0c2c190eb67834ceaafc53eedb75d29c6a/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f7376672e6c617465783f5c4c617267652673706163653b582854293d5c6c6566745b585f302b585f315c6c656674285c667261637b545f307d7b547d2d315c7269676874295c72696768745d5c6c656674285c667261637b545f307d7b547d5c7269676874295e7b585f327d)
(I might possibly want to add a few more from lineshapemodel.h later.)