Dear all,
I very much appreciate the powerful features of the new solver - calculating
tracks around territory etc. It also might be scientifically correct what
John says, however the results are sometimes very difficult to understand and
appear not plausible at first sight. This can confuse the pilot or at least
add addtional load to his flying, while trying to make sense of the values
instead of looking for a safe outlanding site.
Therefore, I very much prefer the "old" solver, the one implemented in Vers.
6.0.10 I believe. Also, since most glide computers eg. LX series, work the
old fashioned way the redundancy of having to separate computers e.g. XCSoar
and LX5000 and comparing the results gets lots with the new solver.
Since the discussion of using the new or the old solver boils down to personal
and individual preferencies, I very much support the idea of Tobias and let the
user decide, which solver to be used. It might also have the additional
benefit of reducing CPU power for users of old HP PDAs, when selecting the old
solver, of course at the drawback of not being able to consider territory or
airspace in the AltDiffRequired.
Cheers,
Sascha
________________________________
Von: Tobias Bieniek <tobias.bien...@gmx.de>
An: John Wharington <jwharing...@gmail.com>
Cc: "xcsoar-user@lists.sourceforge.net" <xcsoar-user@lists.sourceforge.net>
Gesendet: 17:20 Montag, 21.November 2011
Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released
You are right with your second point about the two airfields, but I
think we should let the pilot figure this out. I guess I would have to
agree that the time spent circling shouldn't be a factor. AFAIK no
other software does it that way... As I mentioned earlier, we could
make it configurable but I don't think that's really useful.
Turbo
2011/11/21 John Wharington <jwharing...@gmail.com>:
> We will have to agree to disagree on that.
> Arrival altitude should indeed consider circling, and you should set a
> reasonable MC value, if you are able to climb. If you don't expect to
> be able to climb, then set MC=0.
>
> If conditions are such that climbing in weak lift makes an upwind
> landing point effectively unreachable, this should be shown. If
> downwind drift due to circling was not taken into account, then
> two airfields just beyond pure glide range would look similarly
> attractive even though in actuality, the downwind one will be much
> more reachable at a low climb rate.
>
> On Tue, Nov 22, 2011 at 3:09 AM, Ramy Yanetz <ryan...@yahoo.com> wrote:
>> Arrival altitude should NEVER consider circling! I never heard of such
>> theory. Arrival altitude should only consider polar, degradation, wind and
>> MC, although it would be fine without considering MC at all. But trying to
>> guess your climb and your drift while climbing is completely wrong. We are
>> not trying to predict the future, we are trying to tell the pilot if he can
>> safely reach an airport or how much he needs to climb.
>>
>> Ramy
>>
>> On Nov 21, 2011, at 5:43 PM, Tobias Bieniek <tobias.bien...@gmx.de> wrote:
>>
>>> John, I think this is inconsistent behaviour... either if you can't
>>> climb you shouldn't see the pure glide value, or if you have a MC
>>> above 0 you shouldn't consider the wind effect while circling. Maybe
>>> for internal calculations we should supply both values and let the
>>> user decide what he wants to see.
>>>
>>> Turbo
>>>
>>>
>>>
>>> 2011/11/21 John Wharington <jwharing...@gmail.com>:
>>>> This is not a bug.
>>>>
>>>> At MC=0, you cannot climb, so the value reported (-500 feet) indicates
>>>> you magically need to gain 500 feet in order to glide at MC=0.
>>>>
>>>> At MC=0.5, you are telling the computer you can climb, and with that
>>>> headwind and a slow climb rate (0.5), you need to climb a lot more.
>>>> In this case, the 500 feet isnt obtained magically, and so the height
>>>> required takes the downwind drift from circling into account.
>>>>
>>>> On Tue, Nov 22, 2011 at 1:34 AM, Ramy Yanetz <ryan...@yahoo.com> wrote:
>>>>> Arrival altitude was at MC =0 was something like -500 feet (500 feet
>>>>> below glide) which was correct. However, With MC=0.5 it was -6000 feet!!!
>>>>> This is obviously a bug since the slight increase in MC will never result
>>>>> in 5000 feet loss.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Xcsoar-user mailing list
>>>> Xcsoar-user@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>>>>
>>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
