Binary orbits incompatible with radial velocities

[t00fri]

Andrew,

Sorry, either an object is approaching or receding. Relabelling the coordinate axes does not change that. Either one of the stars is closer to us, or the other one is. Again, relabelling the coordinate axes does not change this.

This I have of course never contested!

What I implied, however is illustrated in this little drawing:

dzdt_fig.jpg

If the +z axis points towards the observer and the binary star is travelling towards us (i.e.del > 0) then dz / dt > 0.

If the +z axis points away from the observer and the binary star is travelling towards us then dz / dt < 0.

Sure Celestia (and your script) is off the hook if the convention for radial velocities is such that a positive velocity corresponds to motion towards us.

Yes, i.e. if the +z axis points towards the observer, as I suspect it in Celestia (see drawing!).

Can you demonstrate that this is the case - for the four systems I was able to check in the quick test in my previous post (Alpha Centauri, Sigma 2173, 70 Ophiuchi and Chi Draconis) the convention is clearly that the positive velocity corresponds to motion away from us, which means for these systems Celestia is reversed.

I was unable to extract the axis convention for the given radial velocities of that paper. Moreover one always has to separate cleanly between the radial velocity contribution due to orbital movement and movement of the barycenter...I did not see that you've done this cleanly.

There is as yet no evidence that any of the data is using the +ve velocity is towards us convention.

Neither there is evidence for the opposite convention in the dominant number of cases where the convention was not specified.

Fridger

[ajtribick]

Further evidence that your script and Celestia are incorrect.

Attached script compares the Pourbaix barycentre radial velocity V0 with the UVW space motions given in Kinematics of Hipparcos Visual Binaries. I. Stars with Orbital Solutions

Conveniently enough on page 491 the definition of the UVW coordinate system is explicitly stated. So using the RA and Dec in the Hipparcos catalog the star coordinates can be transformed to galactic coordinates (l, b), then the coordinates of the star in the UVW system can be computed, normalising the distance to 1:

U_pos = cos(l) * cos(b)
V_pos = sin(l) * cos(b)
W_pos = sin(b)

It is then possible to explicitly calculate the radial velocity of the system in the convention that positive velocity corresponds to motion away from the Sun by taking the dot product:

RV = U_pos * U_vel + V_pos * V_vel + W_pos * W_vel

Output (star id, V0 in PBX2000, calculated V0):

Code: Select all

HIP 677: -10.00 -11.42
HIP 2941: 18.40 19.82
HIP 4463: -10.40 -10.41
HIP 7580: 47.80 48.96
HIP 8903: -3.10 -3.32
HIP 10064: 12.30 15.54
HIP 10644: -6.60 1.55
HIP 10952: 10.00 9.68
HIP 12390: 15.50 15.95
HIP 12623: -23.03 -22.95
HIP 14328: 3.20 2.51
HIP 20087: 37.86 35.55
HIP 20661: 39.60 39.63
HIP 24608: 29.19 29.30
HIP 28360: -15.80 -17.21
HIP 38382: -21.30 -17.92
HIP 45170: 49.82 50.16
HIP 46404: 55.70 55.41
HIP 57565: 0.50 -0.53
HIP 65378: -6.30 -5.70
HIP 71683: -21.87 -23.84
HIP 73182: 28.10 29.42
HIP 75312: -7.41 -7.24
HIP 85667: -77.18 -77.50
HIP 87895: -32.90 -33.42
HIP 88601: -6.87 -6.95
HIP 89937: 31.90 19.99
HIP 91636: 17.80 16.44
HIP 95995: 11.31 11.06
HIP 96683: 5.20 5.02
HIP 98416: 30.02 29.79
HIP 99376: -43.20 -42.88
HIP 99473: -28.00 -27.67
No space velocities for HIP 103655
HIP 104858: -15.85 -15.74
HIP 104987: -17.60 -16.59
HIP 108917: -10.70 -10.59
HIP 111170: -9.72 -9.28
No space velocities for HIP 111528
HIP 114576: 34.50 7.07

Seems fairly clear to me that the convention when listing radial velocity measurements is that positive corresponds to motion away from us. So far I have not seen a source using the opposite convention, in contrast to the case of binary orbital elements where several conventions exist.

[t00fri]

Andrew,

it remains unclear to me what we can really learn about our question from your additional calculation & comparison. You continue presenting further "supports" (but NOT proofs) for your views without even commenting about my previous simple arguments (drawing). In my view, the essential remaining task is to prove or disprove the presumed direction of Celestia's +z axis.

Quite obviously, we should search also within Celestia's code e.g. for sign or frame inconsistencies rather than discussing further contrived calculations that are entirely independent of Celestia's code.

Seems fairly clear to me that the convention when listing radial velocity measurements is that positive corresponds to motion away from us. So far I have not seen a source using the opposite convention,...

As an example I had listed above a drawing of the used frame from the Univ Berkeley lecture about the RV derivation. There indeed the +z axis pointed towards the observer! Since you didn't comment about it either, I have no idea whether you noticed it at all...

I think it is not useful to lead our discussion about the sign in question at the level of individual "gut feelings". Conventions mean choices that everyone is free do make at his/her gusto without affecting the physics! Probabilistic considerations really don't lead us further here.

Instead, I would consider it most useful, if we could wrap up the status of our quest in form of the single most solid evidence that came up so far.

What would you consider to be your strongest argument, forgetting about arguments with unspecified conventions or other remaining ambiguities. Moreover, suppose we adopt your attitude, would there remain any individual inconsistent star systems at our present level of understanding?

Before modifying my script or Celestia's code we do need to find a real bug or clearcut inconsistency.

Fridger

[t00fri]

Andrew,

hoping that we can reduce our problem to its essentials, I have expanded my above drawing.
The resulting TWO drawings allow to read off immediately the 3rd property given the two others:

1) +z axis pointing {towards | away from} observer ( a free choice!)
2) star moving {towards | away from} observer
3) radial velocity dz / dt { positive | negative}

The implications of the drawings involve only elementary math and are free of prejudice or speculations!

First, let's consider the convention that the
+z axis points towards the observer:
Then we face TWO scenarios:

rv_defs11.jpg

As I emphasized previously, this convention was used in a Berkely Univ. lecture being devoted to a most detailed derivation of the radial velocity equation:

http://astro.berkeley.edu/~kclubb/pdf/RV_Derivation.pdf

Here is the (handdrawn) drawing from that lecture as a reminder:


Next, the remaining possibility that
+z axis points away from observer
Then we again face TWO scenarios:

rv_defs21.jpg

+++++++++++++++++++++++++++++++++++++++++
Do you agree with the implications in these figures??
+++++++++++++++++++++++++++++++++++++++++

If yes, the remaining tasks are:

a) to find out for sure what +z axis convention the RV data in SB9 used. I volunteer to
write an email to Prof. Pourbaix, if you want.

b) to find out for sure what +z axis convention underlies Celestia's prediction of binary orbits in the skyplane!

c) to examine whether there are any remaining inconsistencies between data and Celestia's
sky-plane predictions.

Fridger

[t00fri]

Andrew,

here comes the solution of our convention issue:

I found two respectable sources that specify the convention explicitly. Both agree!

a) Cornell University, Dept. of Astronomy: Astro 4410,
Some Notes on Radial Velocities
Quote:
http://coursewiki.astro.cornell.edu/Ast ... Velocities
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
There is a sign convention associated with radial velocity. Positive signs denote recession, that is, redshifted lines.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

b) Wikipedia: Radial velocity
Quote:
http://en.wikipedia.org/wiki/Radial_velocity
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A negative radial velocity indicates the distance between the source and observer is or was decreasing.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Looking at my two above figures that cover all possible alternatives, we see that
the convention corresponds to my second figure: Here it is once more:

rv_defs21.jpg

So, I hope it became clear that my Binary script spectbins.pl did not contain a bug. In ignorance about that (hidden) astronomical convention, I just happened to pick the other equally possible sign convention.

As I emphasized earlier, differing conventions are perfectly legal, one only needs to make sure that those conventions are the same when comparing data from different sources or when comparing data with theoretical expressions. A perfectly consistent option would thus be to transform the SB9 radial velocity data to my script convention that corresponds to my figure ONE above.

Hence I continue disagreeing with the title of this long long thread...

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
However now that things seem cleared up, I also prefer to perform this simple convention switching in my Binary scripts.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Fridger

PS:

Here is another source specifying the coinciding sign convention:
http://astro.unl.edu/classaction/questi ... rsign.html

And yet another coinciding source:

Astropedia:
http://rr-lyr.ast.obs-mip.fr/astropedia ... 002.en.php
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sign convention for radial velocities: Positive signs denote recession, that is, redshifted lines.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[ajtribick]

So, I hope it became clear that my Binary script spectbins.pl did not contain a bug. In ignorance about that (hidden) astronomical convention, I just happened to pick the other equally possible sign convention.

Physics... it's always those pesky factors of two and minus signs isn't it?

Interesting question is what to do with the visual binaries... for these systems there is a degeneracy between the two orientations (unless spectroscopic data has been used to resolve the degeneracy in certain cases), so changing them to match the standard convention for the angles is not necessarily going to improve the representation.

[t00fri]

Andrew,

So, I hope it became clear that my Binary script spectbins.pl did not contain a bug. In ignorance about that (hidden) astronomical convention, I just happened to pick the other equally possible sign convention.

Physics... it's always those pesky factors of two and minus signs isn't it?

This time we spent our time on a minus sign referring to a mere convention mismatch. But much worse are those minus signs in physics that really decide about exciting new opportunities! For example, the negative sign of the QCD beta function that opened the door to asymptotic freedom and thus to computability at hard momentum scales...

Interesting question is what to do with the visual binaries... for these systems there is a degeneracy between the two orientations (unless spectroscopic data has been used to resolve the degeneracy in certain cases), so changing them to match the standard convention for the angles is not necessarily going to improve the representation.

I'll come forward soon with a little patch for my binary scripts, trying to change a minimum there. Though I feel, a few initial comments about that +z axis convention and a boolean "zaxis flag" would be good. This way one can easily switch between the two alternatives. Perhaps this might be useful for visualbins.pl. Not sure yet. The best determined binaries are those few that are both visually resolvable and spectroscopic. We got most of them in either type of script. Somewhat less easy is once more Grant's nearstars.stc for a number of reasons.

I'll place the patch in here for testing, as soon as time allows.

For Celestia.Sci I am thinking about coding a "LED" indicator next to the distance display on the top left. The LED's color will be a measure for whether the selected binary star is approaching (increasingly blue color) or recessing (increasingly red color) or neither (white). The colors stand for the Doppler wavelength shift, of course.

How do you like such a gadget?

Fridger

[ajtribick]

deleted

[t00fri]

File header is shamelessly stolen from Fridger's version and updated accordingly.

Well done!

With your clever formulation of giving only credits to that trivial header file of mine, you have efficiently done away with all traces to the fact that

• it was me who had the original idea of reading out by computer the leading scientific binary orbit catalogs already 7 years ago,
• that it was me who put it all into Perl and .stc data files already 7 years ago and ever since,
• and finally that it was me who argued convincingly that the RV issue was nothing but a convention dependent sign rather than a physics bug as you originally claimed.

I had thought that during your UK-based physics formation you have learned how scientists tend to give proper and notably fair credits ...

Fridger

[ajtribick]

Deleted solution.

Apologies, I was only thinking of this as part of this ongoing thread, in which context the attribution and history have been discussed already and are pretty clear, rather than regarding the file (which is still actually work-in-progress due to the various other issues involving interaction with other catalogue files, certainly wasn't in any way considering this as anywhere near ready to release into Celestia) as a more stand-alone thing. My bad.

New version coming soon with this resolved and a few other updates...

[ajtribick]

A further update on this fix.

Rewritten version of spectbins.stc to fix the coordinate system, and the following issues:

• Used quaternion multiplication for transformations, this is easier to understand than the original calculation.
• Removed the dependency on non-public, undocumented datafiles
• Added download capability so the script can retrieve all the datafiles. (Note this includes a download of the WDS ~15.9 MB)
• Use WDS data for secondary magnitudes
• Exclude systems with missing secondary magnitudes

Output of running script:

Code: Select all

Getting data from http://aas.aanda.org/index.php?option=com_article&access=standard&Itemid=129&url=/articles/aas/full/2000/14/ds9259/node2.html...
Getting SB9 data from ftp://cdsarc.u-strasbg.fr/pub/cats/B/sb9/main.dat...
Getting WDS data from http://ad.usno.navy.mil/wds/Webtextfiles/wdsweb_summ.txt...
Executing Simbatch script...
HIP 4463 skipped: missing secondary magnitude
HIP 8903 skipped: missing secondary magnitude
HIP 10064 skipped: missing secondary magnitude
HIP 10644 skipped: missing secondary magnitude
HIP 12390 skipped: missing secondary magnitude
HIP 12623 skipped: missing secondary magnitude
HIP 57565 skipped: missing secondary magnitude
HIP 65378 skipped: missing secondary magnitude
HIP 95995 skipped: missing secondary magnitude
HIP 99473 skipped: missing secondary magnitude
HIP 104987 skipped: missing secondary magnitude
HIP 111170 skipped: missing secondary magnitude
Output 28 systems.

Note this is still a work-in-progress, it does not take into account conflicts with other Celestia datafiles, e.g. visualbins.stc and nearstars.stc. I am planning on addressing visualbins.stc in the near future. My current inclination (pun not intended) is to reverse the priority of systems from visualbins.stc and spectbins.stc: currently if a system is in both then the visualbins version is used, however only with spectroscopic data can the orientation degeneracy be resolved.

Attached image shows the delta Equulei system viewed from the direction of Earth with both the (updated) spectbins.stc and visualbins.stc orbits plotted, as you can see the skyplane orbits match as expected.

[t00fri]

Andrew,

- Fix incorrect coordinate system for orbit transformations

I insist that there was nothing INCORRECT in the coordinate system that I used. This sentence should be reformulated properly. The coordinate system I used simply did not match the sign convention (z-axis) corresponding to the radial velocity data that you included later.

So far in the 10 years of my Celestia dev experience, we have NEVER replaced the entire files written by other devs in case of minor changes (physicswise). While I understand your desire for beautifications here and there, this procedure of yours eliminates the exploratory and tedious work by the original author for no good reasons. The minor changes of your version 2.0 could have easily added in form of a patch!

As I explained to you privately, I have also used quaternions to derive my original transformations. Yet I displayed the more ugly non-quaternionic form in my spectbins.pl script to allow for a direct comparison with Grant's results. This has now become impossible.

The problematic overlaps are not in visualbins.stc versus spectbins.stc, but in Grant's nearstars.stc.

Fridger

[ajtribick]

I insist that there was nothing INCORRECT in the coordinate system that I used. This sentence should be reformulated properly. The coordinate system I used simply did not match the sign convention (z-axis) corresponding to the radial velocity data that you included later.

Well somehow your "not incorrect" choice of coordinate system gave wrong results. Maybe it was a wrong coordinate system instead of an incorrect one perhaps? As for including the radial velocity data "later", the clue here is in the name of the type of system: the fact is you failed to check the spectroscopic binaries against the spectroscopic data and therefore chose a coordinate system that placed the stars incorrectly with respect to their relative distance from the solar system.

I call that an incorrect coordinate system I'm afraid. Because it was certainly not the correct one.

And let me just address something you said earlier...

and finally that it was me who argued convincingly that the RV issue was nothing but a convention dependent sign rather than a physics bug as you originally claimed.

I was claiming this was a coordinate system error from the first post in this thread. I call this a bug, because when a program gives incorrect output for a given input that is pretty much the definition of the term "bug".

So far in the 10 years of my Celestia dev experience, we have NEVER replaced the entire files written by other devs in case of minor changes (physicswise). While I understand your desire for beautifications here and there, this procedure of yours eliminates the exploratory and tedious work by the original author for no good reasons. The minor changes of your version 2.0 could have easily added in form of a patch!

Yes well this brings us on to further deficiencies in your scripts. Fact is they rely on data files whose format and origin you failed to document, and you also failed to provide these data files (or at least failed to tell anyone where you provided these files in the script or any of the non-existent documentation). This makes these scripts utterly useless for anyone else who wants to run them, unless they go through a painful process of reverse engineering. So we're looking at patching a large proportion of the script, which is written essentially as one method with zillions of global variables floating all over the place. At which point I decide that rather than trying to patch my way around all these issues it is easier to do a ground-up rewrite.

Alternatively you could have fixed this issue if you'd bothered to do the appropriate consistency checks it at any point since you introduced these binaries data files. Maybe you've fixed it in a way you're happy with in Celestia.Sci, but over here at Celestia we've still got to fix it ourselves since you decided to go your own way.

[t00fri]

:roll:

Well somehow your "not incorrect" choice of coordinate system gave wrong results. Maybe it was a wrong coordinate system instead of an incorrect one perhaps? As for including the radial velocity data "later", the clue here is in the name of the type of system: the fact is you failed to check the spectroscopic binaries against the spectroscopic data and therefore chose a coordinate system that placed the stars incorrectly with respect to their relative distance from the solar system.

I thought this point has finally been clarified! Obviously NOT. As I pointed out earlier, the RV data and the RV theoretical prediction do each depend on a z-axis sign convention. Here is the reminder:
viewtopic.php?f=3&t=15994&start=43

Either sign convention is physically admissible, yet theory and experiment need to refer to the SAME one, of course In my original script the z-axis convention did NOT match the z-axis convention that referred to the RV data that you used. I was admittedly unaware about the fact that in this field there is a wide agreement about which convention to take. Yet, as always: conventions cannot be physically INCORRECT per se!

So far in the 10 years of my Celestia dev experience, we have NEVER replaced the entire files written by other devs in case of minor changes (physicswise). While I understand your desire for beautifications here and there, this procedure of yours eliminates the exploratory and tedious work by the original author for no good reasons. The minor changes of your version 2.0 could have easily added in form of a patch!

Yes well this brings us on to further deficiencies in your scripts. Fact is they rely on data files whose format and origin you failed to document, and you also failed to provide these data files (or at least failed to tell anyone where you provided these files in the script or any of the non-existent documentation). This makes these scripts utterly useless for anyone else who wants to run them, unless they go through a painful process of reverse engineering.

This is really getting offensive now!

• ALL used data files are documented in my script header. I was suffering for YEARS (before you were part of dev) that I was unable to add my data files to the sources, because of reasons of space!
  Addition of those data files to the sources is absolutely trivial, of course. No need for writing a new script. In particular, since throughout my script, there are ample comments about which scientific data file is being read in under which name. Of course, what you called undocumented data files (SB9.txt, Pourbaix-stars.txt, Pourbaix-orbits.txt) are just the originals apart from possibly some skipped header lines or e.g. ##### lines. stars.txt and revised.stc are the familiar Celestia star files.
  
  The SIMBATCH output file 'simbad_spect.txt' is a bit special, since some hand-editing is sensible here. Since that file is just 19 kB it can easily be added to the script. The SIMBATCH input file is much shorter even.
  
  That's it as to undocumented files...
  
  
• It was me who introduced this whole approach into Celestia many years ago to extract (and document) scientific data from published catalogs via PERL and thus make Celestia a truely scientific-level software! This applies not only to the binaries, but to my 10000+ galaxies and the globulars.
  
  
• It was me who told you recently, how to load the scientific data files via ftp within PERL.
  viewtopic.php?f=23&t=16824&start=5
  
  Now you use that simple modification as an argument for replacing my scripts ...hmm!
  
  
• I am using PERL for scientific purposes since the days you were still in "Kindergarden". Most object oriented additions did not exist at the time. But I can assure you that given my vast PERL experience over decades, I am not amused by your critique of my PERL style that is perfectly reliable and well commented.

So we're looking at patching a large proportion of the script, which is written essentially as one method with zillions of global variables floating all over the place.

In my original spectbins.pl, I actually use quite a few methods: RotOrbits{}, clean{}, ss{} and update{}. In other Celestia PERL scripts I used many, many more, depending on demand.

At which point I decide that rather than trying to patch my way around all these issues it is easier to do a ground-up rewrite.

That sort of argument could be applied to MANY code files in Celestia. E.g. to render.cpp! But first, Chris would not allow a replacement and second, I would not consider doing it, for reasons of respect and fairness towards the person (Chris) who wrote the first version implementing a host of original ideas ...

Think about it...

Moreover, as to spectbins.pl, we are talking about a pure service script that will be run only rarely to generate the actual data that Celestia needs. Hence there are no performance arguments whatsoever that might justify a different or more modern script architecture, for example. All that counts for Celestia is the spectbins.stc file!

Maybe you've fixed it in a way you're happy with in Celestia.Sci, but over here at Celestia we've still got to fix it ourselves since you decided to go your own way.

Please, don't forget that I am still a co-author and dev of Celestia, despite having mostly moved into "passive mode" for reasons we both know. Most other devs have become passive, too. Yet, this is NO reason whatsoever to start replacing the traces of their previous relevant work via some "rewrite" and adopt authorship, instead. You could have reminded me about doing a patch, for example. Actually, there were a couple of further reasons why I was unable to do coding both for celestia.Sci and Celestia, recently. Incidentally, I also didn't read much of you since end of May!

Fridger

[ajtribick]

I thought this point has finally been clarified! Obviously NOT. As I pointed out earlier, the RV data and the RV theoretical prediction do each depend on a z-axis sign convention. Here is the reminder:
viewtopic.php?f=3&t=15994&start=43

Either sign convention is physically admissible, yet theory and experiment need to refer to the SAME one, of course In my original script the z-axis convention did NOT match the z-axis convention that referred to the RV data that you used. I was admittedly unaware about the fact that in this field there is a wide agreement about which convention to take. Yet, as always: conventions cannot be physically INCORRECT per se!

Utterly irrelevant. You picked the wrong one. It gave wrong results, irrespective of whether it was physically consistent or not.

ALL used data files are documented in my script header. I was suffering for YEARS (before you were part of dev) that I was unable to add my data files to the sources, because of reasons of space!
Addition of those data files to the sources is absolutely trivial, of course. No need for writing a new script. In particular, since throughout my script, there are ample comments about which scientific data file is being read in under which name. Of course, what you called undocumented data files are largely the originals apart from possibly some skipped header lines or e.g. ##### lines.

The Simbatch data file was utterly undocumented. I still have no idea what it was you originally ran for this. The format the script expected the Pourbaix data (which is not available online in machine-readable format, requires extracting it out of the HTML page) was not documented. When it comes to your binaries scripts, I know where to get the data from but not how to get it.

[*] It was me who introduced this whole approach into Celestia many years ago to extract (and document) scientific data from published catalogs via PERL and thus make Celestia a truely scientific-level software! This applies not only to the binaries, but to my 10000+ galaxies and the globulars.

Great, well done. None of that makes your code gospel or infallible.

[*] I am using PERL for scientific purposes since the days you were still in "Kindergarden". Most object oriented additions did not exist at the time. But I can assure you that given my vast PERL experience over decades, I am not amused by your critique of my PERL style that is perfectly reliable and well commented. [/list]

There is a reason why coding styles have evolved over the years. A fair amount of that has to do with maintainability. In short your code being essentially one large blob that hardly even makes the level of "procedural" is more difficult to maintain than it should be. If we followed this logic we'd have to allow for some of the source code to be written on punch-cards because people were using that way back then and they still managed to get the job done.

That sort of argument could be applied to MANY code files in Celestia. E.g. to render.cpp! But first, Chris would not allow a replacement and second, I would not consider doing it, for reasons of respect and fairness towards the person (Chris) who wrote the first version implementing a host of original ideas ...

Think about it...

Replacement of code is a normal part of software development I'm afraid, code isn't gospel. And having code which can be improved in another part of a project does not justify not making improvements elsewhere.

Moreover, as to spectbins.pl, we are talking about a pure service script that will be run only rarely to generate the actual data that Celestia needs. Hence there are no performance arguments whatsoever that might justify a different or more modern script architecture, for example. All that counts for Celestia is the spectbins.stc file!

It becomes an issue when it turns out there is a bug in the output and it turns out that running the script is impossible because of undocumented input files that are required for its operation.

Please, don't forget that I am still a co-author and dev of Celestia, despite having mostly moved into "passive mode" for reasons we both know. Most other devs have become passive, too. Yet, this is NO reason whatsoever to start replacing the traces of their previous relevant work and adopt authorship, instead. You could have reminded me about doing a patch, for example.

This thread has been going on as a reminder that there is an issue with the binaries for just over a year now.

Incidentally, I also didn't read much of you since end of May!

Yes indeed. I was considering whether it was worth spending my free time on a project where bad faith is the default assumption on the part of the major participants. There are other things I can spend my time on you know.

[t00fri]

I thought this point has finally been clarified! Obviously NOT. As I pointed out earlier, the RV data and the RV theoretical prediction do each depend on a z-axis sign convention. Here is the reminder:
viewtopic.php?f=3&t=15994&start=43

Either sign convention is physically admissible, yet theory and experiment need to refer to the SAME one, of course In my original script the z-axis convention did NOT match the z-axis convention that referred to the RV data that you used. I was admittedly unaware about the fact that in this field there is a wide agreement about which convention to take. Yet, as always: conventions cannot be physically INCORRECT per se!

Utterly irrelevant. You picked the wrong one. It gave wrong results, irrespective of whether it was physically consistent or not.

Did you perhaps leave Physics too early?

The crucial point is that my code by itself is NOT incorrect, since physicswise I am free to choose the z-axis and I did not consider the RV data in the script. The RV data defined wrto an opposite z-axis would be equally correct, yet this represents an unpopular convention among the RV community. Clearly these data would look different from the data you used but would be compatible with my script results. There is not more and not less to this issue.

In our case, a real bug would be independent of picking frames! What happened here is merely an incompatible frame choice between my theoretical result and a sign convention in the data that you and others used. To properly compare with my script results one needs to choose the opposite z-axis for the RV data, which is physicswise permissible yet unpopular! You used the popular choice instead and found a contradiction.

As physicists we know many analogous cases in other areas. E.g. measurements and predictions of polarizations! Whenever data are defined as projections on some vector, the same issue arises.

The Simbatch data file was utterly undocumented. I still have no idea what it was you originally ran for this. The format the script expected the Pourbaix data (which is not available online in machine-readable format, requires extracting it out of the HTML page) was not documented. When it comes to your binaries scripts, I know where to get the data from but not how to get it.

I was still editing my previous post, when you read it. Please look again at the final statement concerning the SIMBATCH and other "undocumented" files!

[*] It was me who introduced this whole approach into Celestia many years ago to extract (and document) scientific data from published catalogs via PERL and thus make Celestia a truely scientific-level software! This applies not only to the binaries, but to my 10000+ galaxies and the globulars.

Great, well done. None of that makes your code gospel or infallible.

If you go ahead with your "beautifications" and associated total replacements of original code and authors , this whole important DSO part of Celestia will soon be associated with your name rather than mine...

Why don't you start instead with some real C++/OGL coding to live up to your new Celestia assignment? How about providing at last e.g. some nice shader star renderings to Celestia instead of rewriting other peoples' service scripts?

Fridger

[ajtribick]

Fridger,

You have had ample opportunity in this time to present a fix for this issue that you would be happy with. Instead you choose to keep insulting me, denying you made any mistake whatsoever, assumed bad faith on my part when I presented the fix the first time (yes I got the credits wrong, but that was your choice to assume I was maliciously trying to remove evidence of your contributions), and generally been obstructive to resolving the issue.

As for your last comment, I've got other priorities right now. If you want to do something else, feel free to contribute them here, or if you don't want to do that create your own fork and develop what you want to develop on that. Either way, we should not leave the data files in a wrong state just to preserve the purity of your credit on them.

[t00fri]

Fridger,

You have had ample opportunity in this time to present a fix for this issue that you would be happy with.

Since May 13 (when I thought we had reached agreement about this whole issue), I had unfortunately NO opportunity to work on Celestia or celestia.Sci:

1) I had to take a major operation and only returned from hospital a couple of weeks ago. Now I am getting used to the > 8 inch "pirate scar" across my belly.

2) As I wrote to you privately, our daughter is getting married end of the coming week here, and hence the preparations / organizations for a pretty large party of guests left absolutely no spare time in the recent past.

Instead you choose to keep insulting me, denying you made any mistake whatsoever, assumed bad faith on my part when I presented the fix the first time (yes I got the credits wrong, but that was your choice to assume I was maliciously trying to remove evidence of your contributions), and generally been obstructive to resolving the issue.

Sorry but your above style of writing was insulting first. I am reluctant to expand on this now.

As to the credits issue, well this was a "hammer", but I have clearly accepted your apologies and your promise to come up with an improvement. Unfortunately your announced "improvement" was only marginal progress.

...and generally been obstructive to resolving the issue.

This can't be serious!? I have worked really hard (and politely!) throughout this year of our joint RV arguments to make you accept the underlying reason for this formal disagreement between calculation and RV data. Unfortunately, it seems I failed miserably. For a theoretical physicist this apparent "disagreement" is a quite familiar issue whenever data AND theory both depend on certain conventions.

So here I am really curious why you feel I was obstructive to resolving the issue.

As for your last comment, I've got other priorities right now. If you want to do something else, feel free to contribute them here, or if you don't want to do that create your own fork and develop what you want to develop on that. Either way, we should not leave the data files in a wrong state just to preserve the purity of your credit on them.

I promise, I'll prepare a fix for spectbins.pl. But because of summer activities it may still take a while. Anyway, I'll do it ASAP. If you prefer, I add your quaternionic method for the transformations (credited to you, of course). As I explained, the reasons for casting my own quaternionic calculations into the "explicit" form was historical. Of course, I'll also improve on the file definitions issues (as done, too in celestia.Sci).

Last not least: I am of course always open for astrophysically motivated improvements of my code by other devs. But this cannot be a total replacement of my physically correct initiating code to the extent that my visible contribution shrinks to a 1 line residual with my name (with PhD unduely skipped ) . While I think I made this quite clear above, your above generic reply

Replacement of code is a normal part of software development I'm afraid, code isn't gospel. And having code which can be improved in another part of a project does not justify not making improvements elsewhere.

was entirely besides the point.


Fridger

[ajtribick]

Do what you want. I'm out.

I really don't see much point in creating bad feelings by messing with people's pet code. I've got other things to be spending my free time on.

Enjoy the summer.