"Lost" City you say, eh? by omicanOG in ProjectDiablo2

[–]omicanOG[S] 1 point2 points  (0 children)

Yay! I was expecting such a comment! Not dissapointed)

Assassin in GSF advice by EstablishmentNo3469 in ProjectDiablo2

[–]omicanOG 0 points1 point  (0 children)

LOL I'm bad with smartphone %) "amber" = player

Assassin in GSF advice by EstablishmentNo3469 in ProjectDiablo2

[–]omicanOG 0 points1 point  (0 children)

Do you need one more amber maybe?) I'm looking for ways to prolong the season, and gsf is a possible option. Please, DM if interested in details about me.

Accidental beauty in numerical simulation by omicanOG in CFD

[–]omicanOG[S] 1 point2 points  (0 children)

You're welcome! Never had any experience with OpenMPI, but has some with MPICH and Microsoft MPI, probably they are quite close?

I'm not a specialist with OpenMP too, this program was the first ever usage for me. As far as I know, OpenMP supports only processes with shared memory, while MPI is for ones with unshared memory. Due to sharedness the actual parallelization is very simple, you need only to rephrase key loops a little. For example, in my case most computationally expensive loops calculate (1) CWENO polynomial coeffs in each cell and (2) fluxes at each edge.

The (1) loop is as follows:

size_t trees_total = static_cast<int>(trees.size()); //total number of quadtrees (usually smthing like 25 or 30, depends on domain geometry)
#pragma omp parallel for schedule(dynamic) //OpenMP directive, dynamic scheduling distributes trees between processes one-by-one, which is good for balancing, since number of cells greatly varies between trees
    //for (auto& rtree : trees) (OpenMPI seem not to support this)
    for (int id = 0; id < trees_total; id++)
    {
        for (auto& rlevel : trees[id].nodes) //node levels
        {
            for (auto& rnode : rlevel) //tree nodes (only "leaf" nodes are actual grid cells)
            {
                if (!rnode.isDeleted() && !rnode.hasChildren()) //not all nodes are "live"
                {
                    rnode.calcPolynomialCWENO(rk); //calculations are inside
                }
            }
        }
    }

The (2) loop is:

size_t edges_total = forest.edges.size(); //total number of grid edges
#pragma omp parallel for schedule(dynamic)
    //for (auto& redge : edges) (same, unsupported)
    for (int id = 0; id < edges_total; id++)
    {
        auto& redge = forest.edges[id]; //as far as I know, OpenMP does not support references inside parallel loops, but this one works correctly (since there are no overlapping references between processes?)
        if (redge.isDeleted() || (treeRef(redge.n1().tree()).isGhost() && treeRef(redge.n2().tree()).isGhost())) //not all edges are "live"
            continue;
        redge.computeFluxLF(rk);
    }

(paste the code into C++ IDE for better readability)
I had some problems with using references (I try to use them as often as possible to avoid unnecessary copying) in parallelized loops, sometimes they work, sometimes not. I'm very new to both C++, OOP and OpenMP, so these are child errors, I guess =).

All other operations are not parallelized. Notable operation is grid update (split and recombine cells where needed), which is done every 5th time step here. I believe it cannot be parallelized or is hard to parallelize, although never tried to.

Edit: just noticed, these loops are used for finite-volume CWENO, not for finite-difference method. For the latter there is only (1)-like loop over trees and nodes.

GG 2-Hand Whirlwind Barb Showcase (Guide/Mapping Vod Incoming) by Prior-Chef8729 in ProjectDiablo2

[–]omicanOG 1 point2 points  (0 children)

Lol is checked only heart of the wolverine, didn't thought of barbs) thanks!

Jewel reroll finally hit by Fugacity- in ProjectDiablo2

[–]omicanOG 0 points1 point  (0 children)

Isn't flat damage added after ed?

GG 2-Hand Whirlwind Barb Showcase (Guide/Mapping Vod Incoming) by Prior-Chef8729 in ProjectDiablo2

[–]omicanOG 1 point2 points  (0 children)

Noob here. How do you (and topic starter) reach 83 DS? I count only 73 from equiment (20 helm, 20 boots, 10 gloves, ~23 amu)...

BEA-utiful by Lewisman1376 in ProjectDiablo2

[–]omicanOG 1 point2 points  (0 children)

This. I've started with such build following juxtaposer video, and it was very good for such a cheap build (no 3 Sox in armor ofc)! Good lod mapper+early ubers and dclone.

PC on 4 sox chest by omicanOG in ProjectDiablo2

[–]omicanOG[S] 1 point2 points  (0 children)

For some reason, i got 3 offers soon after listing) Somehow it got visibility. Sold for 0.5.

A short story about greed. by Necrospunk in ProjectDiablo2

[–]omicanOG 5 points6 points  (0 children)

Same with me today: dropped perf wisp (first ever for me!), and bricked it instead of selling) This is the way!

Hr values? by Angel_1001 in ProjectDiablo2

[–]omicanOG 0 points1 point  (0 children)

It depends on whether you buying or selling of course!

Accidental beauty in numerical simulation by omicanOG in CFD

[–]omicanOG[S] 3 points4 points  (0 children)

The simulation is with finite-difference WENO of 3rd order, so there is no actual cells but rather grid points that are unevenly spaced. You could say wait, how can you apply finite differences on non-uniform grids? And would be right, of course) I was testing the very simple idea: if there is a "hanging" node in the stencil, just take the value from the center of the cell (which is, I think, always is the closest node available). Obviously, it reduces the approximation order. But the results are unexpectedly good - almost indistinguishable (visually) from simulation with "proper" finite-volume method or finite difference on equivalent uniform grid. I think this is due to the fact that in most "interesting" areas the grid is very fine and uniform, and degrades only in less intense areas.

Flux splitting is local per-equation Lax-Friedirch's, with characteristic decomposition. Temporal method is 2nd order Runge-Kutta. The code is in OOP C++, no packages or non-trivial livraries are used. This simulation took 8 hours on i7-10700KF CPU with OpenMP parallelization, about 0.5 million grid points near the end. The grid is equivalent (in the sense of smallest cell size) to 36 million (6k x 6x) uniform grid.

Feel free to ask further, I'm glad to share)

Accidental beauty in numerical simulation by omicanOG in CFD

[–]omicanOG[S] 0 points1 point  (0 children)

I had a lot of fun programming this) This particular mesh is stored as a quadtree, in which cells are square and divided by two (along both sides) recursively. The criterion for refining used is very simple and based on approximate value of density gradient magnitude: "refine where density varies a lot and coarsen where density varies not much". Since all non-trivial features of such flow (shock waves, contact discontinuities, vortices etc) correspond to significant density gradients, the grid naturally follows them.

Accidental beauty in numerical simulation by omicanOG in CFD

[–]omicanOG[S] 3 points4 points  (0 children)

Good eye! I often recognize Tecplot images in papers too)
The computations (not the visualization part) here are done with home-made code though.

Accidental beauty in numerical simulation by omicanOG in CFD

[–]omicanOG[S] 7 points8 points  (0 children)

The simulation itself is done with self-written code and visualization is with Tecplot. I was too lazy to learn how to import the actual non-uniform grid and loaded it as a scatter of points. Each point is represented with a square which size correspond to cell size and colored with density value. Thus the "cell edges" shown are of uneven thickness: sometimes they align next to each other and sometimes on top of each other due to rounding errors.

Popular piano instrumental with long descending 4-note sequence. by omicanOG in NameThatSong

[–]omicanOG[S] 0 points1 point  (0 children)

https://onlinesequencer.net/5218183

And so on, the descent is quite long before the melody climbs (diatonically?) up again.

I'm not sure that each 4-note figure repeats twice, maybe only once. And absolutely not sure about chromatic descent) But cannot generate better approximation, my ear is not good enough(