Logo by Maya - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Check out the originating "3d Mandelbulb" thread here
 
*
Welcome, Guest. Please login or register. September 21, 2018, 06:41:27 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Glitches and crashes  (Read 1772 times)
0 Members and 1 Guest are viewing this topic.
CmdrKeen
Forums Newbie
*
Posts: 8



« on: June 24, 2015, 11:40:40 PM »

Hi, I've liked browsing the Mandelbrot set since running Fractint on a 286 in the early 90s, so despite being in a position to appreciate the speed of Fractal eXtreme on modern machines, I am certainly thrilled by the new(?) era of perturbation theory. Hence, I recently tried Mandel Machine for the first time – unfortunately not with much luck: I seem to have a choice between crashes and (more than) glitches.

So, when activating any of the special instruction sets (SSE2, SSE3, AVX), MM crashes when zooming past at about E-12, practically irrespective of the region. Sometimes it manages to write a history entry, resulting in an immediate crash after restart. Attached you find Java's debugging information for an example crash.

In case the instruction sets remain deactivated, the interation depth seems to vary rather randomly below the value I've actually set, at least from about E-16. Unfortunately, there seems to be no rule to this – varying the zoom depth in the location dialog alone doesn't change the apparent number of iterations, but zooming with the mouse somehow appears to convince MM to add more detail (or remove it when zooming out). The only way of guaranteeing a 'full' picture is deactivating the perturbation algorithm.

I'd be happy to provider further data or even a Skype screen session. Seemingly being the only one with these problems, I wonder if I am going something wrongly...

* hs_err_pid8940.log.txt (27.05 KB - downloaded 285 times.)
Logged
Botond Kósa
Fractal Lover
**
Posts: 233



WWW
« Reply #1 on: June 25, 2015, 02:05:20 PM »

Hi and welcome to this forum!

Mandel Machine should run flawlessly on your configuration (Intel Sandy Bridge CPU, Window 7 SP1 x64, Java8 x64). Were you using the latest version available (1.3.15)? From the dump file you posted, I can see the function where the crash happened, but the exact line number is not logged unfortunately. Could you also post the exact location (.mmf file) you tried to render? Or at least the last successfully rendered location, which can be found in the history folder.

I am planning to alter the history module to save the location before starting to render, so that unsuccessful locations will also be included.

Regards,
Botond
Logged

Check out my Mandelbrot set explorer:
http://web.t-online.hu/kbotond/mandelmachine/
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #2 on: June 28, 2015, 11:11:36 PM »

Yes, I am using 1.3.15. One example location that is just a fraction of a zoom from a crash away is the following:
Code:
position.re=-0.0624237564189957863
position.im=0.8345136109258122866
position.magnification=43.67183690889952
position.rotation=0.0
computation.iteration_limit=1000

But, as mentioned, the problem is practically independent from the location.
Logged
Botond Kósa
Fractal Lover
**
Posts: 233



WWW
« Reply #3 on: June 30, 2015, 01:31:45 AM »

Yes, I am using 1.3.15. One example location that is just a fraction of a zoom from a crash away is the following:
Code:
position.re=-0.0624237564189957863
position.im=0.8345136109258122866
position.magnification=43.67183690889952
position.rotation=0.0
computation.iteration_limit=1000

But, as mentioned, the problem is practically independent from the location.

That zoom depth is just before MM switches from double to extended precision (long double) calculations. I tried your location and zoomed in a bit but could not reproduce the crash, the image was rendered correctly.

There might be a subtle bug in the extended precision codepath that gets masked on most machines, but comes out on yours. Try the following:
1. Load the location you posted. Check in the Statistics box the precision used to calculate the image. It should be "52 (double)".
2. In the Computation box change the Prec. bits from "Automatic" to "120 (BigNum02)". This forces the usage of arbitrary precision arithmetics even when extended precision would be enough (in the zoom range between 43 and 55).
3. Zoom into the image a few times. If no crash happens, the bug is in the extended codepath. Let me know your findings.
Logged

Check out my Mandelbrot set explorer:
http://web.t-online.hu/kbotond/mandelmachine/
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #4 on: June 30, 2015, 03:15:27 AM »

1. Load the location you posted. Check in the Statistics box the precision used to calculate the image. It should be "52 (double)".
It does, and keeping it at "double" prevents the crash.

Quote
2. In the Computation box change the Prec. bits from "Automatic" to "120 (BigNum02)". This forces the usage of arbitrary precision arithmetics even when extended precision would be enough (in the zoom range between 43 and 55).
Unfortunately, the program then crashes immediately (when special instruction sets are activated). It does so with any other setting than "double" (okay, I haven't tried all the "BigNum"s), even with no zoom, i.e. for the default image.

Further observations when – as opposed to the scenario above – the special instruction sets are not activated:
• Without any zoom and "auto" precision bits, "extended" uses 100% CPU at 99.9% of image generation.
• When explicitly choosing 120 precision bits, and 11, 14 or 15 scale bits, MM freezes at 0% of image generation (well, closing it or drawing one final zoom box is still possible) without CPU load.  For 31, it displays an erroneous image. (Perhaps these are not meant to be used together, but the UI allows it.)
• When crossing the zoom threshold with more than "double", all the values in the section "PT scale distribution" switch from "n/a" to "NaN %".
• As mentioned previously, when leaving all settings at "auto", iteration depth varies depending on the zoom level. The "PT scale distribution" then shows 100% "double".
Logged
Botond Kósa
Fractal Lover
**
Posts: 233



WWW
« Reply #5 on: June 30, 2015, 10:35:00 AM »

Unfortunately, the program then crashes immediately (when special instruction sets are activated). It does so with any other setting than "double" (okay, I haven't tried all the "BigNum"s), even with no zoom, i.e. for the default image.
That might indicate that the bug is somewhere in the PT (perturbation theory) codepath. By default PT is used when standard double precision calculations are not enough, from about 53 zooms. Have you tried to render an image with PT disabled? (Uncheck Use perturbation algorithm under Computation/Heuristics.

• Without any zoom and "auto" precision bits, "extended" uses 100% CPU at 99.9% of image generation.
That is normal. MM should use 100% CPU when the Worker threads under Computation are set to the maximum.

• When explicitly choosing 120 precision bits, and 11, 14 or 15 scale bits, MM freezes at 0% of image generation (well, closing it or drawing one final zoom box is still possible) without CPU load.  For 31, it displays an erroneous image. (Perhaps these are not meant to be used together, but the UI allows it.)
The scale bits control the data type used when performing perturbation calculations. But unless you uncheck Use lower scale data types under Computation/Heuristics, the data type with the lowest suitable scale will be used.
The freeze might be related to the other bug.
For 31 scale bits (ASFloat data type), the image is bogus indeed, thanks for pointing that out.

• When crossing the zoom threshold with more than "double", all the values in the section "PT scale distribution" switch from "n/a" to "NaN %".
This might also be related to the original bug. NaNs could be the result of a division by zero.

• As mentioned previously, when leaving all settings at "auto", iteration depth varies depending on the zoom level. The "PT scale distribution" then shows 100% "double".
I don't really understand this. Could you give an example of the varying iteration depth?
Logged

Check out my Mandelbrot set explorer:
http://web.t-online.hu/kbotond/mandelmachine/
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #6 on: June 30, 2015, 11:31:41 AM »

That might indicate that the bug is somewhere in the PT (perturbation theory) codepath. By default PT is used when standard double precision calculations are not enough, from about 53 zooms. Have you tried to render an image with PT disabled? (Uncheck Use perturbation algorithm under Computation/Heuristics.
Yes, then it works; that's what I meant by
Quote
The only way of guaranteeing a 'full' picture is deactivating the perturbation algorithm.
Then, all the other problematic combinations are rendered harmless.

Quote
MM should use 100% CPU when the Worker threads under Computation are set to the maximum.
I'm sorry for not being clearer about this: I meant that after reaching 99.9% of the image immediately, the program gets stuck at that stage, uses 100% of all cores yet does (apparently) not progress at all any more.

Quote
I don't really understand this. Could you give an example of the varying iteration depth?
Sometimes, sufficient iteration detail is not added when zooming. The three attached images demonstrate this, as they are named by their width. The last image looks as 'bad' as it does despite an iteration limit of 100000. Zooming further adds some detail, but rarely enough to get more than an image of just curvy line between two areas.


* 5.1e-18.jpg (56.11 KB, 640x480 - viewed 147 times.)

* 3.6e-18.jpg (68.6 KB, 640x480 - viewed 140 times.)

* 1.1e-18.jpg (56.64 KB, 640x480 - viewed 142 times.)

* 1.3e-20.jpg (18.15 KB, 640x480 - viewed 139 times.)
« Last Edit: June 30, 2015, 10:50:23 PM by CmdrKeen » Logged
Botond Kósa
Fractal Lover
**
Posts: 233



WWW
« Reply #7 on: June 30, 2015, 11:27:00 PM »

Did you render those images with perturbation enabled and Scale bits set to 11 (scaled double)? The flat areas you see on the images seem to be glitches introduced by the perturbation algorithm. Automatic glitch correction doesn't work yet with scaled doubles, this is a known issue. Try to render with Scale bits set to 14 (extended) and Use lower scale data types turned off.
Logged

Check out my Mandelbrot set explorer:
http://web.t-online.hu/kbotond/mandelmachine/
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #8 on: June 30, 2015, 11:54:45 PM »

Yes, perturbation was active, and I think Scale bits was set to "Auto". When I manually set it to 11 or 15, it semi-freezes: no change in the picture, 100.0% progress alleged, controls are greyed-out but the config boxes are collapsible, the fractal window is movable and zoom boxes can be drawn, albeit to no effect. When set to 14 Scale bits, the program crashes immediately.

The location where I now tried this:
Code:
position.re=0.36073088656004941983713
position.im=0.64014650840841850595581
position.magnification=58.284526860971546
position.rotation=0.0
computation.iteration_limit=100000
« Last Edit: July 01, 2015, 10:18:08 PM by CmdrKeen » Logged
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #9 on: July 18, 2015, 01:53:44 AM »

Today, I updated my Java version to 8u51, and to my delight there are neither crashes nor glitches any more in MM. smiley

Perhaps it was Java's fault all along, although in the list of bug fixes, none catches my eye as a likely culprit.

By the way, now that I can use your great program without impediment, I note that before glitches are corrected, they are drawn in black. Perhaps you could avoid drawing an area before it is confirmed not to need further glitch correction. This way, the visually zoomed version of the base image would directly be replaced by the proper final picture, creating a much smoother zooming experience.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #10 on: July 18, 2015, 04:56:35 PM »

By the way, now that I can use your great program without impediment, I note that before glitches are corrected, they are drawn in black. Perhaps you could avoid drawing an area before it is confirmed not to need further glitch correction. This way, the visually zoomed version of the base image would directly be replaced by the proper final picture, creating a much smoother zooming experience.
I think that is a great idea! smiley
When zooming in, the previous view is stretched into view, so the glitch areas wouldn't be empty, just "pixelated".
Now that we can trust the glitch detection method it is not necessary to display the glitches at all.

For debugging purposes it is good to have the ability to turn it on or off though.
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #11 on: July 18, 2015, 07:03:56 PM »

Now that we can trust the glitch detection method
Well, there are some places where the default settings leave glitches unfixed, one example being:
Code:
position.re=-0.10109636385058862443730696619161422544082082284445883253974074162442527378784411445895985360455127133949584769214756072474047181063562290746838046103366175393057182199420096964895994946626394142797603336934508484682786910570653315
position.im=0.95628651080944972945026960741887337472165892858825145416111752935835973477550146571518189992832161709010684219052220502191638532304211484159441721297910791218226109711505250799904150481942533132932875522284172431199225406195380107
position.magnification=746.5504390679071
position.rotation=0.0
computation.iteration_limit=500000
These particular glitches (top right and bottom left) are fixed when setting the "Scale bits" to anything other than "Automatic" or deactivating either "Ignore delta0 if negligible" or "Use lower scale data types".
Logged
CmdrKeen
Forums Newbie
*
Posts: 8



« Reply #12 on: August 04, 2015, 05:41:14 PM »

By the way, I have numerous other locations with glitches, but I guess it's more efficient if I test them on the next version given that there have already been changes to the code. If you disagree, I could certainly post the locations.

One other thing: The graphics viewer XnView reports read errors with the PNG files that MM produces. When I sent its developer an example file, he didn't give me any hint on what exactly is wrong but just suggested to toggle an option in XnView to ignore certain errors, which solved the problem for me. Just in case you want to fix this nevertheless – the tool pngcheck outputs:
Quote
CRC error in chunk IDAT (computed f1836f2b, expected 00000000)
Logged
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #13 on: August 04, 2015, 06:09:44 PM »

Sounds like the CRC (cyclic redundancy check) field isn't filled in by mandel machine - this is used to detect errors in the stream data, so if the CRC is bad even if all the data is fine some software won't like it (and you won't be able to detect real errors).

http://www.w3.org/TR/PNG/#D-CRCAppendix has a simple implementation of the CRC algorithm, search the document to figure out exactly what needs to be put into the CRC...

personally I found it easier to just use libpng, despite its setjmp hell of error handling, which might not translate well to languages other than C... http://www.libpng.org/pub/png/
Logged
Pages: [1]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Pertubation Theory Glitches Improvement Announcements & News « 1 2 ... 5 6 » Pauldelbrot 82 11087 Last post January 07, 2017, 07:37:03 AM
by quaz0r
About bugs and glitches Movies Showcase (Rate My Movie) SeryZone 2 426 Last post June 02, 2014, 11:00:15 PM
by SeryZone
00019 1.14e382 WIP (now with glitches) Images Showcase (Rate My Fractal) « 1 2 » stardust4ever 19 1332 Last post October 30, 2014, 11:08:53 PM
by Kalles Fraktaler
Nasty glitches... Kalles Fraktaler Gallery PieMan597 1 419 Last post April 04, 2015, 01:56:14 PM
by Kalles Fraktaler
minor gui glitches Bug Reporting taurus 2 220 Last post November 06, 2016, 09:33:06 PM
by taurus

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.242 seconds with 29 queries. (Pretty URLs adds 0.018s, 2q)