<div dir="ltr"><div><b>Polar Align</b></div>I just tried polar alignment and 2 things were a litle bit worse than I remembered:<div><br><div>1) The slew, capture and solver were quick, but after the successful solve it said: "Please wait while WCS data is processed" and this took 10-20s per iteration. I don't ever remember this delay before.</div><div><br></div><div>2) The process wasn't as reliable as it used to be. It used to polar aligned really reliably (e.g after doing it, then retrying, it would tell me I was withing 30 arc-seconds). Now, though I moved the target just to where I wanted, it would tell me I was off by 1.5 arc-minutes (twice).  </div><div><br></div><div>Anything change with polar align recently? Could this be the StellarSolver solving near the pole? Anyone else tried this? Is there a particular configuration I should use for this?</div><div><br></div><div><b>Flats</b></div><div>Took a bunch of flats and saw a minor issue in the fitsviewer hfr display.</div><div>Sent MR <a href="https://invent.kde.org/education/kstars/-/merge_requests/127">https://invent.kde.org/education/kstars/-/merge_requests/127</a></div><div><br></div><div>Hy</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 6:39 PM Hy Murveit <<a href="mailto:murveit@gmail.com">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Jasem,<div><br></div><div>I see you removed the meridian flip options set in the polar alignment, which is a good thing. Thanks.</div><div>However, there's still</div><div>     Options::setAutoWCS(false);<br>     Options::setAstrometrySolverWCS(true);</div><div>which might benefit from the MR I sent.</div><div>Do you want to me to withdraw my MR and you can deal with that as you see fit, or do you want me to modify my MR</div><div>to drop the exectureMeridianFlip, but still keep those two?</div><div>Thanks,</div><div>Hy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 2:51 PM Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I looked into the issue with executeMeridianFlip unchecking itself, and, yes, it was in the polar align code.<div>I have submitted an MR, see <a href="https://invent.kde.org/education/kstars/-/merge_requests/126" target="_blank">https://invent.kde.org/education/kstars/-/merge_requests/126</a> (Jasem, please double check for me that this makes sense to you.)</div><div>As I say in the MR comment, but I feel it's important enough to repeat here:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><p><i>Honestly, this isn't a 100% fix.  I believe it is a fix worth doing, as it will solve the
problem much of the time (as long as the user explicitly exits the polar align).</i></p></div><div><p><i>However, if the user simply leaves polar align without clicking 'done' (e.g. by just clicking on the
Solution Results sub-tab) then his/her flags won't be restored.
Polar align should not be messing with the user's Options--there should be another way of preventing the MF.
That said, it's too close to the release for me (with limited knowledge of align) to re-wire the thing.
I'd recommend that someone more familiar with align refactors/re-organizes at some point
so that Options::executeMeridianFlip() is never changed inside of polar align.</i></p></div></blockquote><div>
<p>Hy</p><p>PS I did find an odd issue while doing this.</p><p>Stderr or stdout spewed hundreds of lines like: </p></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><p>Error: seeking, reading, or closing file /tmp/internalSextractorSolver_21.solved: Invalid argument<br>Error: seeking, reading, or closing file /tmp/internalSextractorSolver_21.solved: Invalid argument<br>Error: seeking, reading, or closing file /tmp/internalSextractorSolver_21.solved: Invalid argument<br>...</p></div></blockquote><div><p>when I tried to polar align with the simulator (I was using profile: "Internal SEP/Internal Solver/4-SmallScaleSolving"). Does this ring a bell?</p></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 1:27 PM Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would say it's been pretty solid for me the last few days. I've tried to test every night when possible. Good work folks!<div><br></div><div>Two things I wanted to bring up:</div><div><br><div>#1. There was one thing I was looking into, going to try again right now.</div><div>I think this would be a good thing to fix for 3.5.0 if I can find the fix and it is straightforward.</div><div>Occasionally, though I try to set it so that it's always enabled, the Meridian Flip Checkbox sometimes</div><div>mysteriously is not set when I start Ekos.  </div><div><br></div><div>This has led to missed flips & a few tripod collisions for me over the past year (though now I mostly always </div><div>remember to check if it's on). A friend recently privately reported to me that the same thing happened to him last week.</div><div>I suspect the polar alignment code is to blame, (I noticed it unchecks and later re-checks the option) but not sure yet.</div><div><br></div><div>#2. I'm not thrilled that Align's star-extraction profiles default to a profile labeled "<i>Default profile. Generic and not optimized for any specific purpose</i>".</div><div>I would rather it defaulted to one of the profiles optimized for Align--e.g. Small Scale Solving. Or, perhaps some middle </div><div>ground between Small Scale and Large Scale. What do you think?</div><div><br></div><div>Hy</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 1:04 PM Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com" target="_blank">mutlaqja@ikarustech.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Folks,<div><br></div><div>So back to this topic, any major blockers to the KStars 3.5.0 release now?</div><div><br></div><div>1. Remote Solver should be fixed now.</div><div>2. StellarSolver Profiles are more optimized now.</div><div>3. Handbook not updated yet, but we can probably work on this shortly.</div><div>4. Couple of pending MRs to take care of.</div><div><br></div><div>How about Friday the 13th?</div><div><br></div><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 5, 2020 at 3:41 AM Robert Lancaster <<a href="mailto:rlancaste@gmail.com" target="_blank">rlancaste@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br>
<br>
Ok so then we would be changing the way we do version numbering with this, right?<br>
I believe now we typically add features in each new iteration 3.4.1, 3.4.2, etc etc<br>
and when it is really big like StellarSolver, then we make it a big release like 3.5.0<br>
<br>
With this new paradigm, we wouldn’t put new features into the master of the main 3.5 branch<br>
But instead we would work on a new 3.6 branch, and then bug fixes would go into the 3.5 branch<br>
to make each new minor release, like 3.5.1, 3.5.2 etc.<br>
<br>
Do I have this correct?<br>
<br>
If this is right, then it would be longer before users see new features in the main branch, but the <br>
tradeoff is that the main branch would have a LOT more stability.  I see this as a big positive.<br>
<br>
Thanks,<br>
<br>
Rob<br>
<br>
> On Nov 4, 2020, at 5:54 PM, Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank">eric.dejouhanet@gmail.com</a>> wrote:<br>
> <br>
> Hello Hy,<br>
> <br>
> Version 3.5.0 is only the beginning of the 3.5.x series, with more<br>
> bugfixes on each iteration (and possibly, only bugfixes).<br>
> So I have no problem leaving unresolved issues in 3.5.0.<br>
> <br>
> For instance, the Focus module now has a slight and unforeseeable<br>
> delay after the capture completes.<br>
> The UI reflects the end of the capture only, not the end of the detection.<br>
> This makes the UI Focus test quite difficult to tweak, as running an<br>
> average of the HFR over multiple frames now has an unknown duration.<br>
> Right now, the test is trying to click the capture button too soon 2<br>
> out of 10 attempts.<br>
> But this won't block 3.5 in my opinion (and now that I understood the<br>
> problem, I won't work on it immediately).<br>
> <br>
> In terms of reporting problems, the official way is stil <a href="http://bugs.kde.org" rel="noreferrer" target="_blank">bugs.kde.org</a>,<br>
> but there's quite a cleanup/followup to do there.<br>
> I'd say we can use issues in <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> to discuss planned<br>
> development around a forum/bugzilla issue or invent proposal (like<br>
> agile stories).<br>
> There are milestones associated with several issues (although I think<br>
> they should be reviewed and postponed).<br>
> And we can certainly write a punchlist: check the board at<br>
> <a href="https://invent.kde.org/education/kstars/-/milestones/3" rel="noreferrer" target="_blank">https://invent.kde.org/education/kstars/-/milestones/3</a><br>
> <br>
> Le mer. 4 nov. 2020 à 22:38, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> a écrit :<br>
>> <br>
>> Eric,<br>
>> <br>
>> I would add to your list:<br>
>> <br>
>> - KStars Handbook (review update sections to reflect 3.5.0) and finally (perhaps manually if necessary) put the latest handbook online.<br>
>> <br>
>> - Review the extraction settings. I spent a bit of time looking at the default HFR settings, and based on some experimentation (truth be told, with a limited amount of data) adjust things a little differently than my first guess (which was basically focus' settings).<br>
>> Rob: My intuition is that I should adjust the default StellarSolver star-extraction settings for Focus and Guide as well in stellarsolverprofile.cpp. I don't know whether you've already verified them, and want to release them as they are, or whether they are a first shot and you'd welcome adjustment?<br>
>> <br>
>> Also, Eric, I suppose I should be adding these things here: <a href="https://invent.kde.org/education/kstars/-/issues" rel="noreferrer" target="_blank">https://invent.kde.org/education/kstars/-/issues</a><br>
>> Is that right? Sorry about that--ok, after this thread ;) But seriously, your email is a good summary, and from that link<br>
>> it doesn't seem as easy to see which are "must do by 3.5.0" and which are "nice to have someday".<br>
>> A 3.5.0 punchlist would be a nice thing to have.<br>
>> <br>
>> Hy<br>
>> <br>
>> On Wed, Nov 4, 2020 at 12:58 PM Eric Dejouhanet <<a href="mailto:eric.dejouhanet@gmail.com" target="_blank">eric.dejouhanet@gmail.com</a>> wrote:<br>
>>> <br>
>>> Hello,<br>
>>> <br>
>>> Where do we stand now in terms of bugfixing towards 3.5.0?<br>
>>> <br>
>>> - StellarSolver has all features in, and 1.5 is finally out at Jasem's PPA.<br>
>>> - However Gitlab CI still complains about that lib package (see<br>
>>> <a href="https://invent.kde.org/education/kstars/-/jobs/75941" rel="noreferrer" target="_blank">https://invent.kde.org/education/kstars/-/jobs/75941</a>)<br>
>>> - Unitary tests are being fixed progressively, mount tests are down to<br>
>>> ~20 minutes (yeees!)<br>
>>> - From my tests, the remote Astrometry INDI driver is not usable<br>
>>> anymore from Ekos.<br>
>>> - The issue raised with flat frames is confirmed fixed (at least by me).<br>
>>> - Meridian flip is OK (but I had not enough time to test TWO flips in a row).<br>
>>> - Memory leaks are still being researched in Ekos.<br>
>>> - There is an issue when duplicating an entry in a scheduler job,<br>
>>> where the sequence associated is copied from the next job.<br>
>>> <br>
>>> Could we get a 3.6 branch where we will merge development of new features?<br>
>>> And master for bugfixing 3.5.x until we merge 3.6 new features in?<br>
>>> (we'd still have to port bugfixes from master to 3.6)<br>
>>> I don't think the opposite, master for 3.6 and a separate living<br>
>>> 3.5.x, is doable in the current configuration (build, ppas, MRs...).<br>
>>> <br>
>>> --<br>
>>> -- <a href="mailto:eric.dejouhanet@gmail.com" target="_blank">eric.dejouhanet@gmail.com</a> - <a href="https://astronomy.dejouha.net" rel="noreferrer" target="_blank">https://astronomy.dejouha.net</a><br>
> <br>
> <br>
> <br>
> -- <br>
> -- <a href="mailto:eric.dejouhanet@gmail.com" target="_blank">eric.dejouhanet@gmail.com</a> - <a href="https://astronomy.dejouha.net" rel="noreferrer" target="_blank">https://astronomy.dejouha.net</a><br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>