patchGNU Octave - Patches: patch #9859, missing functions: stream2,...

 
 

patch #9859: missing functions: stream2, stream3, streamline

Submitter:  Hg200 <hg200>
Submitted:  Mon 14 Oct 2019 10:12:11 AM UTC
   
 
Category:  Core : new function Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 08 Dec 2019 04:54:16 PM UTC, comment #7: 

This seems to be working as expected.

Closing as done.

Markus Mützel <mmuetzel>
Group administrator
Sun 01 Dec 2019 04:29:23 PM UTC, comment #6: 

Thanks for fixing the additional style issues that I missed.
I pushed your changeset after adding the new functions to the NEWS file here:
http://hg.savannah.gnu.org/hgweb/octave/rev/992e702ef0d7

It will be part of Octave 6.

Marking as ready for test.

Thanks for the MWE, too. I wasn't aware that this is an issue. I also didn't find an open bug report about this.
Could you please open a new one with your MWE?
I agree that this shouldn't be fixed in each function that draws lines but at a more central location.

Markus Mützel <mmuetzel>
Group administrator
Sun 01 Dec 2019 03:13:49 PM UTC, comment #5: 

Thank you very much for the thorough code review and especially for pointing out to the resize method. In the attached patch you will find:

  • completion with suggested changes (endif, ~->!, spaces etc)
  • added error exit on complex data input (as pointing to complex transpose)
  • one sentence on streamtube color
  • fix copyright / it is not necessary to mention my name in the docu
  • cameraviewanglemode set to manual in streamtube demo


In CFD post-processing it is common practice not to change the size of an object as it is rotated and viewed from different angles. The two questionable statements freeze the current view settings and set the modes to manual. It looks like it does work as well if you just set the FOV to manual


set (gca, 'cameraviewanglemode', 'manual');


But from my side we can also remove the line completely in order to keep the demo as simple as possible (it is not so important for a demo).

To your screenshots: Here it looks exactly the same. This artifact is caused when too many vertices are passed to the line () or plot3 () command. You can run the following MWE and then run it again, where N is reduced to 1000, and look for the differences in the plot output.


N = 20000;
r = linspace (1, 50, N);
phi = linspace (0, 20*2*pi(), N);
x = r.*cos (phi);
y = r.*sin (phi);
z = 20*sin (phi);
line ('xdata', x, 'ydata', y, 'zdata', z, 'color', 'r');
axis equal;
view (3);


I can do a fix in streamline.m. For example, we could pass only every N-th vertex to the line () command. However, then the documentation of line () must contain information about the maximum allowable number of vertices to create a nice plot. Probably a better way would be to make a direct fix in the code of line (but requires knowledge about what causes the rendering problem) because this "feature" could be also beneficial for other programs. What do you think?

(file #47956)

Hg200 <hg200>
Sat 30 Nov 2019 06:21:39 PM UTC, comment #4: 

Thanks again for your high quality contribution.

I went through your patch a bit more thoroughly and only made a few minor changes. E.g:

  • "!" instead of "~" for negations
  • "endif", endfor", ... instead of "end"
  • double quotes instead of single quotes
  • transpose operator ".'" instead of Hermitian transpose "'"
  • Matrix::extract instead of your function "crop_buffer".
  • commit message more to standard.


Additionally, I moved the function back to "corefcn". I previously misunderstood. Please accept my apologies for the additional work that my previous comment has caused.

I'd like to push your contribution. But I don't know the stance on nick names for copyright holders...
Would you mind having you clear name at the copyright?
Alternatively, it might be possible that you transferred your copyright to one of the maintainers. Maybe jwe would accept?

Would you like to be added to the list of acknowledged contributors at the beginning of the manual?

Could you please shed some light on why you use the following construct at the end of the demos in streamtube.m?

%! props = {"cameraviewangle", "dataaspectratio", "plotboxaspectratio"};
%! set (hax, props, get (hax, props));


In "demo stream3", I can see what looks like white lines that partly cover the attractor (more prominent if I rotate the view). Is this intended, or some glitch (on my side?)?


file #47955)

Markus Mützel <mmuetzel>
Group administrator
Sat 23 Nov 2019 02:33:49 PM UTC, comment #3: 

Hi,

#1
thank you for your response. I have moved the source file to dldfcns. My question is what flags do i have to give in libinterp/dldfcn/module-files if i don't use any extra libraries?

#2
As far as accuracy is concerned, I've done tests using three different methods that are often used for streamline integration (for example see Paraview's Stream Tracer). These were

- Single Step Euler (explicite)
- Heun's Scheme
- Runge Kutta 4th-Order

The attached PDF shows a benchmark 3D problem on a 6x6x11 grid, including the analytic streamline solution. In order to penalize the different computational effort, the step size of the Heun Scheme was set twice and the RK4 step size four times as high as Euler's (20 steps/cell). Euler Single Step does not converge very well, while Heun and RK4 are in good agreement with the analytic solution.

In fact it is possible to implement all three methods into one patch. However, then the function interface must be changed to provide a choice and it will increase also code size. Therefore, in the attached patch the Euler- and RK4 integrators were removed and Heun's Scheme was kept. You can run 'demo streamline' to see the benchmark between Heun's Scheme and the analytic solution.

#3
To examine the impact of the integrator scheme on other functions, I also implemented a streamtube function (missing as well) and added it to the patch. You may run 'demo streamtube'.

#4
Finally one last question (see stream_euler.cc line 112): I was wondering if there is an API solution to easily implement a matrix operation like B=A(1:N,:) or A(N:end,:)=[] ?

best regards


(file #47924, file #47925)

Hg200 <hg200>
Sat 02 Nov 2019 03:32:53 PM UTC, comment #2: 

It would be nice to have implementations of the streamline functions in Octave.
Are you still interested in contributing an updated patch that honours the points you mentioned in comment #1?

If so, maybe also consider adding dynamically loaded functions in "libinterp\dldfcn".

Markus Mützel <mmuetzel>
Group administrator
Sun 20 Oct 2019 01:57:22 PM UTC, comment #1: 

Hello Octave Team,

i want to withdraw my patch. Please don't use the code. The reasons are:

1.) bugs
2.) divisions can be optimized
3.) runge kutta is performing better than single step euler at same computing effort (see picture)

I apologize if i have caused any inconvenience.



Hg200 <hg200>
Mon 14 Oct 2019 10:12:11 AM UTC, original submission:  

A streamline is the trajectory or integral curve which a massless particle undergoes in a velocity field. stream2() and stream3() are functions used to calculate the vertice segments along a trajectory originating from a specific starting point in space. The function streamline() is a wrapper function for stream2 / stream3 and is used to plot the stream lines.

The attached code calculates the streamline trajectory by explicit forward euler iteration of the vector field in canonical coordinates. Hence it was necessary to implement some of the code in C because of runtime issues. So two new core functions (streameuler2d and streameuler3d) are introduced.

This patch took way more effort than i thought.

Hg200 <hg200>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47953:  demo_stream3_1.png added by mmuetzel (101KiB - image/png)
file #47954:  demo_stream3_2.png added by mmuetzel (130KiB - image/png)
file #47955:  patch_streamline-20191123_v2.patch added by mmuetzel (45KiB - application/octet-stream)
file #47924:  benchmark_20191123.pdf added by hg200 (69KiB - application/pdf)
file #47723:  picture.png added by hg200 (281KiB - image/png)
file #47664:  patch_streamline-20191014.diff added by hg200 (28KiB - text/x-patch - Initial Patch (#0))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by hg200 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-08 mmuetzel StatusReady For Test Done
        Open/ClosedOpen Closed
    2019-12-01 mmuetzel StatusIn Progress Ready For Test
    2019-12-01 hg200 Attached File- Added patch_streamline-20191201.patch, #47956
    2019-11-30 mmuetzel Attached File- Added demo_stream3_1.png, #47953
        Attached File- Added demo_stream3_2.png, #47954
        Attached File- Added patch_streamline-20191123_v2.patch, #47955
        StatusNone In Progress
    2019-11-23 hg200 Attached File- Added benchmark_20191123.pdf, #47924
        Attached File- Added patch_streamline-20191123.diff, #47925
    2019-11-02 mmuetzel Summarypatch for missing functions: stream2, stream3, streamline missing functions: stream2, stream3, streamline
    2019-10-20 hg200 Attached File- Added picture.png, #47723
    2019-10-14 hg200 Attached File- Added patch_streamline-20191014.diff, #47664

    Back to the top

    Powered by Savane 3.14-5139.
    Corresponding source code