Modify

Opened 5 years ago

Last modified 5 years ago

#1332 new enhancement

Prolongation operators are only parallelized in one direction

Reported by: Frank Löffler Owned by: Erik Schnetter
Priority: minor Milestone:
Component: Carpet Version: development version
Keywords: Cc:

Description

Currently, Carpet's prolongation operators are only parallelized in one direction (the largest). This happens before calling the actual operator in call_operator() (CarpetLib). With increasing core(thread)-counts this is a problem. There are hardly enough points in any single direction to make this efficient.

Wouldn't it be much better (in terms of openmp efficiency) to let the operators handle openmp-parallelization themselves? I currently see quite a large overhead for real-world parfiles with 32 threads just because of this.

Attachments (0)

Change History (1)

comment:1 Changed 5 years ago by Erik Schnetter

Instead of moving parallelization to a lower level, it would probably be more efficient to move it even higher up. For example, given a single refined region on a single MPI process, its six boundaries should be prolongated in parallel. Doing this efficiently and dynamically requires an infrastructure that is more flexible than a typical OpenMP implementation.

In the short term, using LoopControl (where applicable) in the prolongation operators' loops is probably the best, as you suggest.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
Next status will be 'confirmed'.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.