MFlowCode.github.io/documentation/case.html at master · MFlowCode/MFlowCode.github.io

History

1797 lines (1795 loc) · 228 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

707

708

709

710

711

712

713

714

715

716

717

718

719

720

721

722

723

724

725

726

727

728

729

730

731

732

733

734

735

736

737

738

739

740

741

742

743

744

745

746

747

748

749

750

751

752

753

754

755

756

757

758

759

760

761

762

763

764

765

766

767

768

769

770

771

772

773

774

775

776

777

778

779

780

781

782

783

784

785

786

787

788

789

790

791

792

793

794

795

796

797

798

799

800

801

802

803

804

805

806

807

808

809

810

811

812

813

814

815

816

817

818

819

820

821

822

823

824

825

826

827

828

829

830

831

832

833

834

835

836

837

838

839

840

841

842

843

844

845

846

847

848

849

850

851

852

853

854

855

856

857

858

859

860

861

862

863

864

865

866

867

868

869

870

871

872

873

874

875

876

877

878

879

880

881

882

883

884

885

886

887

888

889

890

891

892

893

894

895

896

897

898

899

900

901

902

903

904

905

906

907

908

909

910

911

912

913

914

915

916

917

918

919

920

921

922

923

924

925

926

927

928

929

930

931

932

933

934

935

936

937

938

939

940

941

942

943

944

945

946

947

948

949

950

951

952

953

954

955

956

957

958

959

960

961

962

963

964

965

966

967

968

969

970

971

972

973

974

975

976

977

978

979

980

981

982

983

984

985

986

987

988

989

990

991

992

993

994

995

996

997

998

999

1000

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

window.dataLayer = window.dataLayer || [];

function gtag(){dataLayer.push(arguments);}

gtag('js', new Date());

gtag('config', 'G-SY496B9L99');

</script>

<title>MFC: Case Files</title>

MathJax.Hub.Config({

extensions: ["tex2jax.js", "TeX/AMSmath.js", "TeX/AMSsymbols.js"],

jax: ["input/TeX","output/HTML-CSS"],

});

// This file is set as MATHJAX_CODEFILE in the Doxyfile. It configures how

// MathJax renders expressions in Markdown so that it is consistent with GitHub.

MathJax.Hub.Config({

extensions: ["tex2jax.js"],

jax: ["input/TeX", "output/HTML-CSS"],

tex2jax: {

inlineMath: [ ['$', '$'], ["\$","\$"] ],

displayMath: [ ['$$','$$'], ["\\[","\\]"] ],

processEscapes: true,

ignoreClass: "line" // Ignore code blocks: https://web.archive.org/web/20120430100225/http://www.mathjax.org/docs/1.1/options/tex2jax.html

"HTML-CSS": {

fonts: ["TeX"]

}

});

</script>

</head>

<body>

<tbody>

<div id="projectname">MFC

</div>

<div id="projectbrief">Exascale flow solver</div>

</td>

</tr>

</tbody>

</table>

</div>

document.addEventListener('DOMContentLoaded', function() {

var nav = document.createElement('div');

nav.id = 'mfc-nav';

var items = [

['../documentation/index.html', 'documentation', 'User Guide'],

['../api/index.html', 'api', 'API Documentation']

];

var path = window.location.pathname;

var apiPaths = ['/api/', '/pre_process/', '/simulation/', '/post_process/'];

for (var i = 0; i < items.length; i++) {

var a = document.createElement('a');

a.href = items[i][0];

a.textContent = items[i][2];

if (items[i][1] === 'api') {

for (var j = 0; j < apiPaths.length; j++) {

if (path.indexOf(apiPaths[j]) !== -1) { a.className = 'active'; break; }

}

} else {

if (path.indexOf('/' + items[i][1] + '/') !== -1) a.className = 'active';

}

nav.appendChild(a);

}

var sideNav = document.getElementById('side-nav');

if (sideNav) sideNav.insertBefore(nav, sideNav.firstChild);

});

</script>

var searchBox = new SearchBox("searchBox", "search/",'.html');

</script>

$(function() { codefold.init(); });

</script>

$(function() {

initMenu('',true,false,'search.php','Search',true);

$(function() { init_search(); });

});

</script>

</div>

</div>

<div id="splitbar" style="-moz-user-select:none;"

class="ui-resizable-handle">

</div>

$(function(){initNavTree('case.html','',''); });

</script>

<div id="MSearchSelectWindow"

onmouseover="return searchBox.OnSearchSelectShow()"

onmouseout="return searchBox.OnSearchSelectHide()"

onkeydown="return searchBox.OnSearchSelectKey(event)">

</div>

<div class="SRStatus" id="Loading">Loading...</div>

<div class="SRStatus" id="Searching">Searching...</div>

<div class="SRStatus" id="NoMatches">No Matches</div>

</div>

<div class="headertitle"><div class="title">Case Files </div></div>

</div>

Case Files</h1>

Example Python case files, also referred to as input files, can be found in the <a href="https://github.com/MFlowCode/MFC/tree/master/examples">examples/</a> directory. They print a Python dictionary containing input parameters for MFC. Their contents, and a guide to filling them out, are documented in the user manual. A commented, tutorial script can also be found in <a href="https://github.com/MFlowCode/MFC/blob/master/examples/3D_sphbubcollapse/case.py">examples/3d_sphbubcollapse/</a>.

Basic Skeleton</h2>

The skeleton for an input file may look like the following:

<div class="fragment"><div class="line">#!/usr/bin/env python3</div>

<div class="line">import json</div>

<div class="line"># Configuring case dictionary</div>

<div class="line">print(json.dumps({</div>

<div class="line"> # Insert case parameters here</div>

</div>Thus, you can run your case file with Python to view the computed case dictionary that will be processed by MFC when you run:

<div class="fragment"><div class="line">python3 my_case_file.py</div>

</div>This is particularly useful when computations are done in Python to generate the case.

(Optional) Accepting command line arguments</h2>

Input files can accept command line arguments, forwarded by mfc.sh run. Consider this example from the scaling case:

<div class="fragment"><div class="line">import json, argparse</div>

<div class="line">parser = argparse.ArgumentParser(</div>

<div class="line"> prog="scaling",</div>

<div class="line"> description="Weak- and strong-scaling benchmark case.",</div>

<div class="line"> formatter_class=argparse.ArgumentDefaultsHelpFormatter)</div>

<div class="line">parser.add_argument("--mfc", type=json.loads, default='{}', metavar="DICT",</div>

<div class="line"> help="MFC's toolchain's internal state.")</div>

<div class="line">parser.add_argument("-s", "--scaling", type=str, metavar="SCALING", choices=["weak", "strong"],</div>

<div class="line"> help="Whether weak- or strong-scaling is being exercised.")</div>

<div class="line"># Your parsed arguments are here</div>

<div class="line">args = parser.parse_args()</div>

</div>The --mfc argument is a JSON string representing mfc.sh run's internal state, passed in when MFC runs your input file. It contains all the runtime information you might want from the build/run system. You can add as many additional arguments and options as you may need.

To run such a case, use the following format:

</div>For example, to run the scaling case in "weak-scaling" mode:

<div class="fragment"><div class="line">./mfc.sh run examples/scaling/benchmark.py -t pre_process -j 8 -- --scaling weak</div>

</div><h2 class="doxsection"><a class="anchor" id="autotoc_md18"></a>

Parameters</h2>

Feature Compatibility</h2>

Before diving into parameter details, check the <a class="el" href="case_constraints.html" title="Case Creator Guide">Feature Compatibility Guide</a> to understand:<ul>

<li>Which features work together (MHD, bubbles, phase change, etc.)</li>

<li>Common configuration patterns with copy-paste examples</li>

<li>Requirements for each model equation and Riemann solver</li>

</ul>

Parameter Lookup:<ul>

<li>CLI search: ./mfc.sh params <query> - Search ~3,300 parameters from the command line</li>

<li>Full reference: <a class="el" href="parameters.html" title="Case Parameters">Case Parameters</a> - Complete parameter documentation</li>

</ul>

There are multiple sets of parameters that must be specified in the python input file:<ol type="1">

<li><a class="el" href="#sec-runtime" title="1. Runtime">Runtime Parameters</a></li>

<li><a class="el" href="#sec-computational-domain" title="2. Computational Domain">Computational Domain Parameters</a></li>

<li><a class="el" href="#sec-patches" title="3. Patches">Patch Parameters</a></li>

<li><a class="el" href="#sec-immersed-boundary-patches" title="4. Immersed Boundary Patches">Immersed Boundary Patches</a></li>

<li><a class="el" href="#sec-fluid-materials" title="5. Fluid Material's">Fluid Material's Parameters</a></li>

<li><a class="el" href="#sec-simulation-algorithm" title="6. Simulation Algorithm">Simulation Algorithm Parameters</a></li>

<li><a class="el" href="#sec-formatted-output" title="7. Formatted Output">Formatted Database and Structure Parameters</a></li>

<li><a class="el" href="#sec-acoustic-source" title="8. Acoustic Source">(Optional) Acoustic Source Parameters</a></li>

<li><a class="el" href="#sec-bubble-models" title="9. Sub-grid Bubble Models">(Optional) Ensemble-Averaged Bubble Model Parameters</a></li>

<li><a class="el" href="#sec-velocity-field-setup" title="10. Velocity Field Setup">(Optional) Velocity Field Setup Parameters</a></li>

<li><a class="el" href="#sec-phase-change" title="11. Phase Change Model">(Optional) Phase Change Parameters</a></li>

<li><a class="el" href="#sec-artificial-mach-number" title="12. Artificial Mach Number">(Optional) Artificial Mach Number Parameters</a></li>

</ol>

Items 8, 9, 10, 11 and 12 are optional sets of parameters that activate the acoustic source model, ensemble-averaged bubble model, initial velocity field setup, phase change, artificial Mach number respectively. Definition of the parameters is described in the following subsections.

Enumerated parameters accept named values as well as integer codes: "riemann_solver": "hllc" is equivalent to "riemann_solver": 2. Defined names appear in each parameter's table entry (e.g. 1 (hll), 2 (hllc)). Existing case files can be rewritten to named syntax with ./mfc.sh validate case.py --migrate.

1. Runtime</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">run_time_info </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Output run-time information </td></tr>

<td class="markdownTableBodyRight">rdma_mpi </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">(GPUs) Enable RDMA for MPI communication. </td></tr>

<td class="markdownTableBodyRight">case_dir </td><td class="markdownTableBodyCenter">String </td><td class="markdownTableBodyLeft">Case directory path </td></tr>

<td class="markdownTableBodyRight">old_grid </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Use grid from previous simulation </td></tr>

<td class="markdownTableBodyRight">old_ic </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Use initial conditions from previous simulation </td></tr>

<td class="markdownTableBodyRight">t_step_old </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Time step to restart from </td></tr>

<td class="markdownTableBodyRight">n_start_old </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Starting index from previous simulation </td></tr>

</table>

<ul>

<li>run_time_info generates a text file that includes run-time information including the CFL number(s) at each time-step.</li>

<li>rdma_mpi optimizes data transfers between GPUs using Remote Direct Memory Access (RDMA). The underlying MPI implementation and communication infrastructure must support this feature, detecting GPU pointers and performing RDMA accordingly.</li>

</ul>

2. Computational Domain</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">x[y,z]_domain%beg[end] </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Beginning [ending] of the $x$[y,z]-direction domain </td></tr>

<td class="markdownTableBodyRight">stretch_x[y,z] </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Stretching of the mesh in the $x$[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">a_x[y,z] </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Rate at which the grid is stretched in the $x$[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">x[y,z]_a </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Beginning of the stretching in the negative $x$[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">x[y,z]_b </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Beginning of the stretching in the positive $x$[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">loops_x[y,z] </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of times to recursively apply grid stretching </td></tr>

<td class="markdownTableBodyRight">cyl_coord </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Cylindrical coordinates (2D: Axisymmetric, 3D: Cylindrical) </td></tr>

<td class="markdownTableBodyRight">m </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of grid cells in the $x$-coordinate direction </td></tr>

<td class="markdownTableBodyRight">n </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of grid cells in the $y$-coordinate direction </td></tr>

<td class="markdownTableBodyRight">p </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of grid cells in the $z$-coordinate direction </td></tr>

</table>

The parameters define the boundaries of the spatial and temporal domains, and their discretization that are used in simulation.

<ul>

<li>[x,y,z]_domain%[beg,end] define the spatial domain in $x$, $y$, and $z$ Cartesian coordinates:

\[ x \in \left[ x\_domain\%beg, \; x\_domain\%end \right], \quad y \in \left[ y\_domain\%beg, \; y\_domain\%end \right], \quad z \in \left[ z\_domain\%beg, \; z\_domain\%end \right] \]

</li>

<li>$m$, $n$, and $p$ define the number of finite volume cells that uniformly discretize the domain along the $x$, $y$, and $z$ axes, respectively. Note that the actual number of cells in each coordinate axis is given as $[m,n,p]+1$. For example, $m=n=p=499$ discretizes the domain into $500^3$ cells. When the simulation is 2D/axi-symmetric or 1D, it requires that $p=0$ or $p=n=0$, respectively.</li>

<li>stretch_[x,y,z] activates grid stretching in the $[x,y,z]$ directions. The grid is gradually stretched such that the domain boundaries are pushed away from the origin along a specified axis.</li>

<li>a_[x,y,z], [x,y,z]_a, and [x,y,z]_b are parameters that define the grid stretching function. When grid stretching along the $x$ axis is considered, the stretching function is given as:

\[ x_{cb,stretch} = x_{cb} + \frac{x_{cb}}{a_x} \Bigg[ \mathrm{log}\left[\mathrm{cosh} \left( \frac{a_x(x_{cb}-x_a)}{L} \right) \right] + \mathrm{log}\left[\mathrm{cosh} \left( \frac{a_x(x_{cb}-x_b)}{L} \right) \right] -2 \mathrm{log}\left[\mathrm{cosh} \left( \frac{a_x(x_b-x_a)}{2L} \right) \right] \Bigg] \]

</li>

</ul>

where x_cb and x_[cb,stretch] are the coordinates of a cell boundary at the original and stretched domains, respectively. L is the domain length along the x axis: L=x_domain%end-x_domain%beg. Crudely speaking, x_a and x_b define the coordinates at which the grid begins to get stretched in the negative and positive directions along the $x$ axis, respectively. $a_x$ defines the smoothness of the stretching. Stretching along the $y$ and $z$ axes follows the same logistics. Optimal choice of the parameters for grid stretching is case-dependent and left to the user. loops_x[y,z] defines the number of times the grid stretching function is applied and has a default value of one.

<ul>

<li>cyl_coord activates cylindrical coordinates. The domain is defined in $x$-$y$-$z$ cylindrical coordinates, instead of Cartesian coordinates. Domain discretization is accordingly conducted along the axes of cylindrical coordinates. When $p=0$, the domain is defined on $x$-$y$ axi-symmetric coordinates. In both Coordinates, mesh stretching can be defined along the $x$- and $y$-axes. MPI topology is automatically optimized to maximize the parallel efficiency for given choice of coordinate systems.</li>

</ul>

3. Patches</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadCenter">Analytical Definition </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">num_patches </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Number of initial condition geometric patches. </td></tr>

<td class="markdownTableBodyRight">num_fluids </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Number of fluids/components present in the flow. </td></tr>

<td class="markdownTableBodyRight">geometry * </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Geometry configuration of the patch. </td></tr>

<td class="markdownTableBodyRight">alter_patch(i) * </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Alter the $i$-th patch. </td></tr>

<td class="markdownTableBodyRight">x[y,z]_centroid * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Centroid of the applied geometry in the $[x,y,z]$-direction. </td></tr>

<td class="markdownTableBodyRight">length_x[y,z] * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Length, if applicable, in the $[x,y,z]$-direction. </td></tr>

<td class="markdownTableBodyRight">radius * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Radius, if applicable, of the applied geometry. </td></tr>

<td class="markdownTableBodyRight">smoothen * </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Smoothen the applied patch. </td></tr>

<td class="markdownTableBodyRight">smooth_patch_id * </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">A patch with which the applied patch is smoothened. </td></tr>

<td class="markdownTableBodyRight">smooth_coeff * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Smoothen coefficient. </td></tr>

<td class="markdownTableBodyRight">alpha(i) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Volume fraction of fluid $i$. </td></tr>

<td class="markdownTableBodyRight">alpha_rho(i) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Partial density of fluid $i$. </td></tr>

<td class="markdownTableBodyRight">pres * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Pressure. </td></tr>

<td class="markdownTableBodyRight">vel(i) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Velocity in direction $i$. </td></tr>

<td class="markdownTableBodyRight">tau_e(i) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Elastic stresses. </td></tr>

<td class="markdownTableBodyRight">hcid * </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">N/A </td><td class="markdownTableBodyLeft">Hard coded patch id </td></tr>

<td class="markdownTableBodyRight">cf_val * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyCenter">Supported </td><td class="markdownTableBodyLeft">Surface tension color function value </td></tr>

<td class="markdownTableBodyRight">model_id </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyCenter">Not Supported </td><td class="markdownTableBodyLeft">Index into the stl_models array (geometry 21) </td></tr>

</table>

*: These parameters should be prepended with patch_icpp(j)% where $j$ is the patch index.

The Table lists the patch parameters. The parameters define the geometries and physical parameters of fluid components (patch) in the domain at initial condition. Note that the domain must be fully filled with patches. The code outputs error messages when an empty region is left in the domain.

<ul>

<li>tau_e(i) is the i-th component of the elastic stress tensor, ordered as tau_xx, tau_xy, tau_yy, tau_xz, tau_yz, and tau_zz. 1D simulation requires tau(1), 2D tau(1:3), and 3D tau(1:6).</li>

</ul>

Analytical Definition of Primitive Variables</h4>

Some parameters, as described above, can be defined by analytical functions in the input file. For example, one can define the following patch:

<div class="fragment"><div class="line">'patch_icpp(2)%geometry' : 1,</div>

<div class="line">'patch_icpp(2)%x_centroid' : 0.25,</div>

<div class="line">'patch_icpp(2)%length_x' : 9.5,</div>

<div class="line">'patch_icpp(2)%vel(1)' : 0.,</div>

<div class="line">'patch_icpp(2)%pres' : 1.,</div>

<div class="line">'patch_icpp(2)%alpha_rho(1)': '1 + 0.1*sin(20*x*pi)',</div>

<div class="line">'patch_icpp(2)%alpha(1)' : 1.,</div>

</div>where alpha_rho is defined with the 1 + 0.1*sin(20*x*pi) function.

Expressions use Python syntax and are parsed at case load time. Syntax errors and unknown variable or function names are immediate, named errors — they are reported before any Fortran is compiled, with a message identifying the offending expression and listing the available names.

The following variables are available in IC patch expressions:

<th class="markdownTableHeadNone">Shorthand </th><th class="markdownTableHeadNone">Expands To </th><th class="markdownTableHeadNone">Shorthand </th><th class="markdownTableHeadNone">Expands To </th><th class="markdownTableHeadNone">Shorthand </th><th class="markdownTableHeadNone">Expands To </th></tr>

<td class="markdownTableBodyNone">x </td><td class="markdownTableBodyNone">x_cc(i) </td><td class="markdownTableBodyNone">lx </td><td class="markdownTableBodyNone">The patch's length_x </td><td class="markdownTableBodyNone">xc </td><td class="markdownTableBodyNone">The patch's x_centroid </td></tr>

<td class="markdownTableBodyNone">y </td><td class="markdownTableBodyNone">y_cc(j) </td><td class="markdownTableBodyNone">ly </td><td class="markdownTableBodyNone">The patch's length_y </td><td class="markdownTableBodyNone">yc </td><td class="markdownTableBodyNone">The patch's y_centroid </td></tr>

<td class="markdownTableBodyNone">z </td><td class="markdownTableBodyNone">z_cc(k) </td><td class="markdownTableBodyNone">lz </td><td class="markdownTableBodyNone">The patch's length_z </td><td class="markdownTableBodyNone">zc </td><td class="markdownTableBodyNone">The patch's z_centroid </td></tr>

<td class="markdownTableBodyNone">eps </td><td class="markdownTableBodyNone">The patch's epsilon </td><td class="markdownTableBodyNone">beta </td><td class="markdownTableBodyNone">The patch's beta </td><td class="markdownTableBodyNone">radii </td><td class="markdownTableBodyNone">The patch's radii </td></tr>

<td class="markdownTableBodyNone">tau_e </td><td class="markdownTableBodyNone">The patch's tau_e </td><td class="markdownTableBodyNone">r </td><td class="markdownTableBodyNone">The patch's radius </td><td class="markdownTableBodyNone">pi </td><td class="markdownTableBodyNone">$\pi$ (Fortran constant from m_constants) </td></tr>

</table>

where $(i,j,k)$ are the grid-indices of the current cell in each coordinate direction.

The allowed functions are the standard Fortran intrinsics: sin, cos, tan, asin, acos, atan, atan2, sinh, cosh, tanh, exp, log, log10, sqrt, abs, min, max, mod, sign.

Euler's number: bare e is not a variable. Write exp(1.0) or a numeric literal instead (e.g. 2.718281828).

In the example above, the following code is generated:

<div class="fragment"><div class="line">if (patch_id == 2) then</div>

</div><h4 class="doxsection"><a class="anchor" id="autotoc_md21"></a>

Hard Coded Patches</h4>

Some patch configurations are not adequately handled with the above analytic variable definitions. In this case, a hard coded patch can be used. Hard coded patches can be added by adding additional hard coded patch identifiers to src/common/include/1[2,3]dHardcodedIC.fpp. When using a hard coded patch, the patch_icpp(patch_id)%hcid must be set to the hard-coded patch id. For example, to add a 2D Hardcoded patch with an id of 200, one would add the following to src/common/include/2dHardcodedIC.fpp

<div class="line"> ! primitive variables assignment</div>

</div>and use patch_icpp(i)%hcid = 200 in the input file. Additional variables can be declared in Hardcoded1[2,3]DVariables and used in hardcoded1[2,3]D. As a convention, any hard coded patches that are part of the MFC master branch should be identified as 1[2,3]xx where the first digit indicates the number of dimensions.

The code provides three pre-built patches for dimensional extrusion of initial conditions:

<ul>

<li>case(170): Load 1D profile from data files</li>

<li>case(270): Extrude 1D data to 2D domain</li>

<li>case(370): Extrude 2D data to 3D domain</li>

<li>case(273): Extrude 1D data to 2D domain, with the mom%beg data column carrying the extruded-axis (mom%end) velocity profile instead of its own (zeroed) component. Used by examples/2D_reacting_mixing_layer to give a temporally-evolving mixing layer a nonzero streamwise velocity profile along the extruded axis, which case(270) cannot represent since it always zeros that component.</li>

<li>case(274): Load a full 2D (x, y) field with no extrusion – one data file per variable, (m_glb+1)*(n_glb+1) lines each in x-major order, covering all primitive variables directly (unlike case(270)/case(273), no component is zeroed or repurposed). Used by examples/2D_spatial_reacting_mixing_layer for a spatially-evolving mixing layer, where the cross-stream profile must vary with the streamwise coordinate too (via the bf_spatial_support body force) so no single extrusion axis applies. The file's line count, origin, and (uniform) cell spacing must match the run grid; a mismatched file is rejected with a fatal error, so regenerate the IC whenever the grid changes.</li>

</ul>

Setup: Only requires specifying files_dir and filename pattern via file_extension. The files are located, for example, at examples/1D_flamelet/IC, and their format is prim.XX.YY.file_extension.dat. Implementation: All variables and file handling are managed in the case.py file of the simulation. Usage: Ideal for initializing simulations from lower-dimensional solutions, enabling users to add perturbations or modifications to the base extruded fields for flow instability studies.

The following parameters support hardcoded initial conditions that read interface data from files:

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">interface_file </td><td class="markdownTableBodyCenter">String </td><td class="markdownTableBodyLeft">Path to interface geometry data file </td></tr>

<td class="markdownTableBodyRight">normFac </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Interface normalization factor </td></tr>

<td class="markdownTableBodyRight">normMag </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Interface normal magnitude </td></tr>

<td class="markdownTableBodyRight">g0_ic </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Gravitational acceleration for the interfacial IC pressure field </td></tr>

<td class="markdownTableBodyRight">p0_ic </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Reference pressure at the interface </td></tr>

</table>

These parameters are only read by the file-based hardcoded-IC patches (hcid = 304 and 305 in src/common/include/3dHardcodedIC.fpp); they are ignored otherwise.

<ul>

<li>interface_file gives the path to a text file that supplies the interface-position field $h(i,j)$ used to place the material interface. The run aborts if the file is not found.</li>

<li>normMag and normFac rescale and offset the raw interface data, $h \leftarrow \texttt{normMag}\,h + \texttt{normFac}$. Each is applied only when set (defaults leave the data unchanged).</li>

<li>p0_ic and g0_ic set the initial (hydrostatic) pressure field about the interface, $p = p_{0} + \rho\, g_{0}\,\big(h - x\big)$, where $x$ is the coordinate normal to the interface.</li>

</ul>

Parameter Descriptions</h4>

<ul>

<li>num_patches defines the total number of patches defined in the domain. The number has to be a positive integer.</li>

<li>num_fluids defines the total number of fluids defined in each of the patches. The number has to be a positive integer.</li>

<li>patch_icpp(j)%geometry defines the type of geometry of $j$-th patch by using an integer from 1 to 21. Definition of the patch type for each integer is listed in table <a class="el" href="#patch-types" title="Patch types">Patch Types</a>.</li>

<li>[x,y,z]_centroid, length_[x,y,z], and/or radius are used to uniquely define the geometry of the patch with given type. Requisite combinations of the parameters for each type are listed in table <a class="el" href="#patch-types" title="Patch types">Patch types</a>.</li>

<li>patch_icpp(j)%alter_patch(i) activates alternation of patch(i) with patch(j). For instance, in a 2D simulation, when a cylindrical patch(2) is immersed in a rectangular patch(1):<ul>

<li>patch_icpp(1)%geometry = 3</li>

<li>patch_icpp(2)%geometry = 2</li>

<li>patch_icpp(2)%alter_patch(1) = 'T'</li>

</ul>

</li>

<li>smoothen activates smoothening of the boundary of the patch that alters the existing patch. When smoothening occurs, fluids of the two patches are mixed in the region of the boundary. For instance, in the aforementioned case of the cylindrical patch immersed in the rectangular patch, smoothening occurs when patch_icpp(2)%smoothen = 'T'. smooth_coeff controls the thickness of the region of smoothening (sharpness of the mixture region). The default value of smooth_coeff is unity. The region of smoothening is thickened with decreasing the value. Optimal choice of the value of smooth_coeff is case-dependent and left to the user.</li>

<li>patch_icpp(j)%alpha(i), patch_icpp(j)%alpha_rho(i), patch_icpp(j)%pres, and patch_icpp(j)%vel(i) define for $j$-th patch the void fraction of fluid(i), partial density of fluid(i), the pressure, and the velocity in the $i$-th coordinate direction. These physical parameters must be consistent with fluid material's parameters defined in the next subsection.</li>

<li>model_id selects the STL/OBJ model for a geometry-21 patch by indexing into the stl_models array. The model file, scaling, and translation, and the inside/outside threshold, are configured on that stl_models entry (see the stl_models section below); a cell is marked inside the model using a winding-number test.</li>

</ul>

Elliptic Smoothing</h4>

Initial conditions in which not all patches support the patch_icpp(j)%smoothen parameter can still be smoothed by applying iterations of the heat equation to the initial condition. This is enabled by adding 'elliptic_smoothing': "T", and 'elliptic_smoothing_iters': N, to the case dictionary, where N is the number of smoothing iterations to apply.

4. Immersed Boundary Patches</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">num_ibs </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of immersed boundary patches </td></tr>

<td class="markdownTableBodyRight">num_stl_models </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of STL/OBJ model entries in the stl_models array </td></tr>

<td class="markdownTableBodyRight">num_particle_clouds </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of particle bed specifications to generate immersed boundary patches from </td></tr>

<td class="markdownTableBodyRight">ib_neighborhood_radius </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Parameter that controls the neighborhood size for IB detection. </td></tr>

<td class="markdownTableBodyRight">many_ib_patch_parallelism </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Parallelize over IB patches instead of grid cells (better for many small patches). </td></tr>

<td class="markdownTableBodyRight">geometry </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Geometry configuration of the patch. </td></tr>

<td class="markdownTableBodyRight">x[y,z]_centroid </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Centroid of the applied geometry in the [x,y,z]-direction. </td></tr>

<td class="markdownTableBodyRight">radius </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Radius, if applicable, of the applied geometry. </td></tr>

<td class="markdownTableBodyRight">airfoil_id </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Index into ib_airfoil array for NACA airfoil geometry patches. </td></tr>

<td class="markdownTableBodyRight">model_id </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Index into stl_models array for STL/OBJ geometry patches. </td></tr>

<td class="markdownTableBodyRight">slip </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Apply a slip boundary </td></tr>

<td class="markdownTableBodyRight">moving_ibm </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Sets the method used for IB movement. </td></tr>

<td class="markdownTableBodyRight">vel(i) </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Initial velocity of the moving IB in the i-th direction. </td></tr>

<td class="markdownTableBodyRight">angular_vel(i) </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Initial angular velocity of the moving IB in the i-th direction. </td></tr>

<td class="markdownTableBodyRight">coefficient_of_restitution </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">A number 0 to 1 describing how elastic IB collisions are </td></tr>

<td class="markdownTableBodyRight">collision_model </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Integer to select the collision model being used for IB collisions. </td></tr>

<td class="markdownTableBodyRight">collision_time </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Amount of simulation time used to resolve collisions </td></tr>

<td class="markdownTableBodyRight">ib_coefficient_of_friction </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Coefficient of friction used in IB collisions </td></tr>

</table>

These parameters should be prepended with patch_ib(j)% where $j$ is the patch index.

STL/OBJ model geometry parameters are set on the stl_models array (indexed by model_id):

<th class="markdownTableHeadLeft">Parameter </th><th class="markdownTableHeadLeft">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyLeft">model_filepath </td><td class="markdownTableBodyLeft">String </td><td class="markdownTableBodyLeft">Path to an STL or OBJ file (not all OBJs are supported). </td></tr>

<td class="markdownTableBodyLeft">model_scale(i) </td><td class="markdownTableBodyLeft">Real </td><td class="markdownTableBodyLeft">Model's scaling factor for component $i$. </td></tr>

<td class="markdownTableBodyLeft">model_translate(i) </td><td class="markdownTableBodyLeft">Real </td><td class="markdownTableBodyLeft">Model's $i$-th component of translation. </td></tr>

<td class="markdownTableBodyLeft">model_threshold </td><td class="markdownTableBodyLeft">Real </td><td class="markdownTableBodyLeft">Winding number threshold above which a cell is marked as inside the model. </td></tr>

</table>

These parameters should be prepended with stl_models(k)% where $k$ is the model index.

Parameter Descriptions</h4>

<ul>

<li>geometry defines the type of geometry of an immersed boundary patch with an integer number. Definitions for currently implemented immersed boundary patch types are listed in table <a class="el" href="#immersed-boundary-patch-types" title="Immersed Boundary Patch Types">Immersed Boundary Patch Type</a>.</li>

<li>x[y,z]_centroid is the centroid location of the patch in the x[y,z]-direction</li>

<li>length_x[y,z] is the length of the patch in the x[y,z]-direction.</li>

<li>radius is the radius to be used for circular patches.</li>

<li>c, t, p, and m specify the parameters for a NACA airfoil (set on the referenced ib_airfoil entry). m is the maximum camber, p is the location of maximum camber, c is the chord length, and t is the thickness. Additional details on this specification can be found in <a href="https://en.wikipedia.org/wiki/NACA_airfoil">NACA airfoil</a>.</li>

<li>slip applies a slip boundary to the surface of the patch if true and a no-slip boundary condition to the surface if false.</li>

<li>For STL/OBJ geometry (geometry 5 or 12), set model_id to index into the stl_models array and specify model_filepath, model_scale, model_translate, and model_threshold on that entry.</li>

<li>moving_ibm sets the method by which movement will be applied to the immersed boundary. Using 0 will result in no movement. Using 1 will result 1-way coupling where the boundary moves at a constant rate and applied forces to the fluid based upon its own motion. In 1-way coupling, the fluid does not apply forces back onto the IB. Using 2 will result in 2-way coupling, where the boundary pushes on the fluid and the fluid pushes back on the boundary via pressure and viscous forces. If external forces are applied, the boundary will also experience those forces.</li>

<li>vel(i) is the initial linear velocity of the IB in the x, y, z direction for i=1, 2, 3. When moving_ibm equals 2, this velocity is just the starting speed of the object, which will then accelerate due to external forces. If moving_ibm equals 1, then this is constant if it is a number, or can be described analytically with an expression.</li>

<li>angular_vel(i) is the initial angular velocity of the IB about the x, y, z axes for i=1, 2, 3 in radians per second. When moving_ibm equals 2, this rotation rate is just the starting rate of the object, which will then change due to external torques. If moving_ibm equals 1, then this is constant if it is a number, or can be described analytically with an expression.

Moving-IB analytic expressions use the same Python syntax and error-reporting as IC patch expressions (see the "Analytical Definition of Primitive Variables" section above). Available variables: x (x_cc(i)), y (y_cc(j)), z (z_cc(k)), t (current simulation time), and r (the IB patch radius). The same intrinsic functions and pi constant apply; bare e is not available.

</li>

<li>coefficient_of_restitution is a number from 0 (exclusive) to 1 (inclusive) describing how elastic IB collisions are. 0 is for perfectly inelastic collisions while 1 is for perfectly elastic collisions.</li>

<li>collision_model is an integer to select the collision model being used for IB collisions. Using 0 disables collisions and collision checking. 1 enables the soft-sphere collision model, where all IBs must be circles or sphere and those IBs can collide with each other as well as walls.</li>

<li>collision_time is approximately the amount of simulation time used to resolve collisions. This is handled by modifying the spring constant used to apply collision forces.</li>

<li>ib_coefficient_of_friction is the coefficient of friction used in IB collisions.</li>

<li>ib_neighborhood_radius controls the size of the neighborhood size. A value of $r$ indicates that any given rank is aware of IBs up to $r$ ranks away. This value defaults to 0, which leaves the radius unset so that it is selected automatically. This parameter is required to strong-scale a case when IBs eventually grow to be larger than one full processor domain wide.</li>

</ul>

Particle Clouds</h4>

A particle cloud is a compact specification of a bed of identical circular (2D) or spherical (3D) immersed boundaries; each cloud is expanded into individual patch_ib particles at startup. Set num_particle_clouds to the number of beds and prepend the parameters below with particle_cloud(j)% where $j$ is the cloud index.

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">x[y,z]_centroid </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Centre of the cloud region in the [x,y,z]-direction. </td></tr>

<td class="markdownTableBodyRight">length_x[y,z] </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Extent of the cloud region in the [x,y,z]-direction for cloud_geometry = 1; ignored by cloud_geometry = 2. </td></tr>

<td class="markdownTableBodyRight">num_particles </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of particles to place in the region. </td></tr>

<td class="markdownTableBodyRight">mass </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Mass of every particle in the cloud. </td></tr>

<td class="markdownTableBodyRight">min_spacing </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Minimum surface-to-surface gap between particles (centres are 2*radius + min_spacing apart). </td></tr>

<td class="markdownTableBodyRight">cloud_geometry </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Shape of the cloud region. </td></tr>

<td class="markdownTableBodyRight">shell_inner_radius </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Inner radius for hemisphere-shell clouds (cloud_geometry = 2). </td></tr>

<td class="markdownTableBodyRight">shell_outer_radius </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Outer radius for hemisphere-shell clouds (cloud_geometry = 2). </td></tr>

<td class="markdownTableBodyRight">seed </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Random seed for reproducible placement (used by packing_method = 1). </td></tr>

<td class="markdownTableBodyRight">packing_method </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Algorithm used to place the particles. </td></tr>

</table>

<ul>

<li>cloud_geometry selects the cloud region:<ul>

<li>1 (box) uses x[y,z]_centroid and length_x[y,z] to define the region.</li>

<li>2 uses x[y,z]_centroid, shell_inner_radius, and shell_outer_radius to define a half-annulus in 2D and a hemisphere shell in 3D. Particle centres are sampled between shell_inner_radius + radius and shell_outer_radius - radius, and the flat plane is kept clear by one particle radius. The flat face is fixed at y_centroid in 2D and z_centroid in 3D; the filled region opens toward positive y in 2D and positive z in 3D. The full shell extent (x[y,z]_centroid +/- shell_outer_radius on the open side, and one particle radius of clearance on the flat-face side) must lie inside the computational domain; a hemisphere shell also requires at least two dimensions (n > 0).</li>

</ul>

</li>

<li>packing_method selects how the num_particles are positioned within the cloud region:<ul>

<li>1 (rejection sampling) draws random positions and rejects any that violate min_spacing, producing a disordered bed. seed makes the placement reproducible.</li>

<li>2 (lattice) places the particles on the optimally dense lattice for the geometry — a triangular lattice in 2D and a face-centered cubic lattice in 3D. The lattice spacing is derived from the particle density (num_particles over the region area/volume); if that spacing is below the required 2*radius + min_spacing, the region is too dense and the run aborts.</li>

<li>Hemisphere-shell clouds currently support rejection sampling only; cloud_geometry = 2 with packing_method = 2 is rejected during input validation.</li>

</ul>

</li>

</ul>

5. Fluid Material's</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">gamma </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Stiffened-gas parameter $\Gamma$ of fluid. </td></tr>

<td class="markdownTableBodyRight">pi_inf </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Stiffened-gas parameter $\Pi_\infty$ of fluid. </td></tr>

<td class="markdownTableBodyRight">Re(1) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Shear viscosity of fluid. </td></tr>

<td class="markdownTableBodyRight">Re(2) * </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Volume viscosity of fluid. </td></tr>

<td class="markdownTableBodyRight">cv ** </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Sffened-gas parameter $c_v$ of fluid. </td></tr>

<td class="markdownTableBodyRight">qv ** </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Stiffened-gas parameter $q$ of fluid. </td></tr>

<td class="markdownTableBodyRight">qvp ** </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Stiffened-gas parameter $q'$ of fluid. </td></tr>

<td class="markdownTableBodyRight">sigma </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Surface tension coefficient </td></tr>

<td class="markdownTableBodyRight">G </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Shear modulus of solid. </td></tr>

</table>

Fluid material's parameters. All parameters except for sigma should be prepended with fluid_pp(i) where $i$ is the fluid index.

*: Parameters that work only with model_eqns = 2.

**: Parameters that work only with model_eqns = 3.

The table lists the fluid material's parameters. The parameters define material's property of compressible fluids that are used in simulation.

<ul>

<li>fluid_pp(i)%gamma and fluid_pp(i)%pi_inf define $\Gamma$ and $\Pi$ as parameters of $i$-th fluid that are used in stiffened gas equation of state.</li>

<li>fluid_pp(i)%Re(1) and fluid_pp(i)%Re(2) define the shear and volume viscosities of $i$-th fluid, respectively.</li>

</ul>

When these parameters are undefined, fluids are treated as inviscid. Details of implementation of viscosity in MFC can be found in Coralic <a class="el" href="citelist.html#CITEREF_coralic15">[14]</a>.

<ul>

<li>fluid_pp(i)%cv, fluid_pp(i)%qv, and fluid_pp(i)%qvp define $c_v$, $q$, and $q'$ as parameters of $i$-th fluid that are used in stiffened gas equation of state.</li>

<li>fluid_pp(i)%G is required for hypoelasticity.</li>

</ul>

Stored-form parameters: The values gamma, pi_inf, and Re(1)/Re(2) are not the raw physical quantities. MFC expects transformed stored forms:<ul>

<li>gamma = $1/(\gamma-1)$, not $\gamma$ itself</li>

<li>pi_inf = $\gamma\,\pi_\infty / (\gamma - 1)$, not $\pi_\infty$ itself</li>

<li>Re(1) = $1/\mu$ (inverse viscosity), not $\mu$ itself</li>

</ul>

Setting gamma = 1.4 for air is a common mistake; the correct value is 1.0 / (1.4 - 1.0) = 2.5. See <a class="el" href="equations.html#sec-stored-forms" title="Stored Parameter Conventions">Stored Parameter Conventions</a> and <a class="el" href="equations.html#sec-material-values" title="Common Material Values">Common Material Values</a> in the Equations reference for the full table.

</blockquote>

6. Simulation Algorithm</h3>

See <a class="el" href="equations.html" title="Equations">Equations</a> for the mathematical models these parameters control.

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">bc_[x,y,z]%beg[end] </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Beginning [ending] boundary condition in the $[x,y,z]$-direction (negative integer, see table <a class="el" href="#boundary-conditions" title="Boundary conditions">Boundary Conditions</a>) </td></tr>

<td class="markdownTableBodyRight">bc_[x,y,z]%vb[1,2,3]‡ </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Velocity in the (x,1), (y, 2), (z,3) direction applied to bc_[x,y,z]%beg </td></tr>

<td class="markdownTableBodyRight">bc_[x,y,z]%ve[1,2,3]‡ </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Velocity in the (x,1), (y, 2), (z,3) direction applied to bc_[x,y,z]%end </td></tr>

<td class="markdownTableBodyRight">model_eqns </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Multicomponent model: [1] $\Gamma/\Pi_\infty$; [2] 5-equation; [3] 6-equation </td></tr>

<td class="markdownTableBodyRight">alt_soundspeed * </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Alternate sound speed and $K \nabla \cdot u$ for 5-equation model </td></tr>

<td class="markdownTableBodyRight">adv_n </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Solving directly for the number density (in the method of classes) and compute void fraction from the number density </td></tr>

<td class="markdownTableBodyRight">mpp_lim </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Mixture physical parameters limits </td></tr>

<td class="markdownTableBodyRight">mixture_err </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Mixture properties correction </td></tr>

<td class="markdownTableBodyRight">time_stepper </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Runge–Kutta order [1-3] </td></tr>

<td class="markdownTableBodyRight">adap_dt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Strang splitting scheme with adaptive time stepping </td></tr>

<td class="markdownTableBodyRight">recon_type </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Reconstruction Type: [1] WENO; [2] MUSCL </td></tr>

<td class="markdownTableBodyRight">adap_dt_tol </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Tolerance for adaptive time stepping in Strang splitting scheme </td></tr>

<td class="markdownTableBodyRight">adap_dt_max_iters </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Max iteration for adaptive time stepping in Strang splitting scheme </td></tr>

<td class="markdownTableBodyRight">weno_order </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">WENO order [1,3,5] </td></tr>

<td class="markdownTableBodyRight">weno_eps </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">WENO perturbation (avoid division by zero) </td></tr>

<td class="markdownTableBodyRight">mapped_weno </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">WENO-M (WENO with mapping of nonlinear weights) </td></tr>

<td class="markdownTableBodyRight">wenoz </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">WENO-Z </td></tr>

<td class="markdownTableBodyRight">wenoz_q </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">WENO-Z power parameter q (only for WENO7) </td></tr>

<td class="markdownTableBodyRight">teno </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">TENO (Targeted ENO) </td></tr>

<td class="markdownTableBodyRight">teno_CT </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">TENO threshold for smoothness detection </td></tr>

<td class="markdownTableBodyRight">null_weights </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Null WENO weights at boundaries </td></tr>

<td class="markdownTableBodyRight">mp_weno </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Monotonicity preserving WENO </td></tr>

<td class="markdownTableBodyRight">muscl_order </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">MUSCL order [1,2] </td></tr>

<td class="markdownTableBodyRight">muscl_lim </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">MUSCL Slope Limiter: [1] minmod; [2] monotonized central; [3] Van Albada; [4] Van Leer; [5] SUPERBEE </td></tr>

<td class="markdownTableBodyRight">muscl_eps </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">MUSCL limiter slope-product threshold (default: hard-coded thresholds; set to 0 for textbook behavior) </td></tr>

<td class="markdownTableBodyRight">int_comp </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Interface Compression [0] Off [1] THINC [2] MTHINC (default 0) </td></tr>

<td class="markdownTableBodyRight">flux_lim </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Flux limiter for post-process: [1] minmod; [2] MUSCL; [3] OSPRE; [4] SUPERBEE </td></tr>

<td class="markdownTableBodyRight">ic_eps </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Interface compression threshold (default: 1e-4) </td></tr>

<td class="markdownTableBodyRight">ic_beta </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Interface compression sharpness parameter (default: 1.6) </td></tr>

<td class="markdownTableBodyRight">riemann_solver </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Riemann solver algorithm: [1] HLL*; [2] HLLC; [3] Exact*; [4] HLLD (MHD or hypoelasticity) </td></tr>

<td class="markdownTableBodyRight">hll_u_interface </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">HLL Method 2 (u-interface) for volume fraction advection (default F) </td></tr>

<td class="markdownTableBodyRight">low_Mach </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Low Mach number correction for HLLC Riemann solver: [0] None; [1] Pressure (Chen et al. <a class="el" href="citelist.html#CITEREF_chen22">[11]</a>); [2] Velocity (Thornber et al. <a class="el" href="citelist.html#CITEREF_thornber08">[54]</a>) </td></tr>

<td class="markdownTableBodyRight">avg_state </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Averaged state evaluation method: [1] Roe average*; [2] Arithmetic mean </td></tr>

<td class="markdownTableBodyRight">wave_speeds </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Wave-speed estimation: [1] Direct (Batten et al. <a class="el" href="citelist.html#CITEREF_batten97">[5]</a>); [2] Pressure-velocity* (Toro <a class="el" href="citelist.html#CITEREF_toro09">[56]</a>) </td></tr>

<td class="markdownTableBodyRight">weno_Re_flux </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Compute velocity gradient using scalar divergence theorem </td></tr>

<td class="markdownTableBodyRight">weno_avg </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Arithmetic mean of left and right, WENO-reconstructed, cell-boundary values </td></tr>

<td class="markdownTableBodyRight">t_step_start </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Simulation starting time step </td></tr>

<td class="markdownTableBodyRight">t_step_stop </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Simulation stopping time step </td></tr>

<td class="markdownTableBodyRight">t_step_save </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Frequency to output data </td></tr>

<td class="markdownTableBodyRight">t_step_print </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Frequency to print the current step number to standard output (default 1) </td></tr>

<td class="markdownTableBodyRight">cfl_adap_dt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">CFL based adaptive time-stepping </td></tr>

<td class="markdownTableBodyRight">cfl_const_dt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">CFL based non-adaptive time-stepping </td></tr>

<td class="markdownTableBodyRight">cfl_dt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Enable CFL-based time stepping </td></tr>

<td class="markdownTableBodyRight">cfl_target </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Specified CFL value </td></tr>

<td class="markdownTableBodyRight">n_start </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Save file from which to start simulation </td></tr>

<td class="markdownTableBodyRight">t_save </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Time duration between data output </td></tr>

<td class="markdownTableBodyRight">t_stop </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Simulation stop time </td></tr>

<td class="markdownTableBodyRight">surface_tension </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Activate surface tension </td></tr>

<td class="markdownTableBodyRight">viscous </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Activate viscosity </td></tr>

<td class="markdownTableBodyRight">hypoelasticity </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Activate hypoelasticity* </td></tr>

<td class="markdownTableBodyRight">riemann_hypo_ADC </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Enable hypo anti-diffusion correction for HLLC/HLLD (default F) </td></tr>

<td class="markdownTableBodyRight">ADC_kappa </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">ADC sensor scaling parameter (default 1.0) </td></tr>

<td class="markdownTableBodyRight">hypo_hll_interface_rhs </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">HLL uses interface-consistent hypo RHS (default F) </td></tr>

<td class="markdownTableBodyRight">igr </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Enable solution via information geometric regularization (IGR) Cao and Schafer <a class="el" href="citelist.html#CITEREF_cao24">[9]</a> </td></tr>

<td class="markdownTableBodyRight">igr_order </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Order of reconstruction for IGR [3,5] </td></tr>

<td class="markdownTableBodyRight">alf_factor </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Alpha factor for IGR entropic pressure (default 10) </td></tr>

<td class="markdownTableBodyRight">igr_pres_lim </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Limit IGR pressure to avoid negative values (default F) </td></tr>

<td class="markdownTableBodyRight">igr_iter_solver </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Solution method for IGR elliptic solve [1] Jacobi [2] Gauss-Seidel </td></tr>

<td class="markdownTableBodyRight">num_igr_iters </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of iterations for for the IGR elliptic solve (default 2) </td></tr>

<td class="markdownTableBodyRight">num_igr_warm_start_iters </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of iterations for the IGR elliptic solve at the first time step (default 50) </td></tr>

</table>

<ul>

<li>* Options that work only with model_eqns = 2.</li>

<li>† Options that work only with cyl_coord = 'F'.</li>

<li>‡ Options that work only with bc_[x,y,z]%[beg,end] = -15 and/or bc_[x,y,z]%[beg,end] = -16.</li>

</ul>

The table lists simulation algorithm parameters. The parameters are used to specify options in algorithms that are used to integrate the governing equations of the multi-component flow based on the initial condition. Models and assumptions that are used to formulate and discretize the governing equations are described in Wilfong et al. <a class="el" href="citelist.html#CITEREF_wilfong26">[59]</a> and Bryngelson et al. <a class="el" href="citelist.html#CITEREF_bryngelson21">[8]</a>. Details of the simulation algorithms and implementation of the WENO scheme can be found in Coralic <a class="el" href="citelist.html#CITEREF_coralic15">[14]</a>.

<ul>

<li>bc_[x,y,z]%[beg,end] specifies the boundary conditions at the beginning and the end of domain boundaries in each coordinate direction by a negative integer from -1 through -16. See table <a class="el" href="#boundary-conditions" title="Boundary conditions">Boundary Conditions</a> for details. Boundary condition patches can be used with non-characteristic boundary conditions. Their use is detailed in <a class="el" href="#boundary-condition-patches" title="Boundary Condition Patches">Boundary Condition Patches</a>.</li>

<li>bc_[x,y,z]%vb[1,2,3] specifies the velocity in the (x,1), (y,2), (z,3) direction applied to bc_[x,y,z]%beg when using bc_[x,y,z]%beg = -16. Tangential velocities require viscosity, weno_avg = T, and bc_[x,y,z]%beg = -16 to work properly. Normal velocities require bc_[x,y,z]%end = -15 or bc_[x,y,z]%end = -16 to work properly.</li>

<li>bc_[x,y,z]%ve[1,2,3] specifies the velocity in the (x,1), (y,2), (z,3) direction applied to bc_[x,y,z]%beg when using bc_[x,y,z]%end = -16. Tangential velocities require viscosity, weno_avg = T, and bc_[x,y,z]%end = 16 to work properly. Normal velocities require bc_[x,y,z]%end = -15 or bc_[x,y,z]%end = -16 to work properly.</li>

<li>model_eqns specifies the choice of the multi-component model that is used to formulate the dynamics of the flow using integers from 1 through 3. model_eqns = 1, 2, and 3 correspond to $\Gamma$- $\Pi_\infty$ model (Johnsen <a class="el" href="citelist.html#CITEREF_johnsen08">[24]</a>), 5-equation model (Allaire et al. <a class="el" href="citelist.html#CITEREF_allaire02">[1]</a>), and 6-equation model (Saurel et al. <a class="el" href="citelist.html#CITEREF_saurel09">[45]</a>), respectively. The difference of the two models is assessed by (Schmidmayer et al. <a class="el" href="citelist.html#CITEREF_schmidmayer20">[47]</a>). Note that some code parameters are only compatible with 5-equation model.</li>

<li>alt_soundspeed activates the source term in the advection equations for the volume fractions, $K\nabla\cdot \underline{u}$, that regularizes the speed of sound in the mixture region when the 5-equation model is used. Requires exactly two fluid components ( $K$ is a two-fluid closure). The effect and use of the source term are assessed by Schmidmayer et al. <a class="el" href="citelist.html#CITEREF_schmidmayer20">[47]</a>.</li>

<li>adv_n activates the direct computation of number density by the Riemann solver instead of computing number density from the void fraction in the method of classes.</li>

<li>mpp_lim activates correction of solutions to avoid a negative void fraction of each component in each grid cell, such that $\alpha_i>\varepsilon$ is satisfied at each time step.</li>

<li>mixture_err activates correction of solutions to avoid imaginary speed of sound at each grid cell.</li>

<li>time_stepper specifies the order of the Runge-Kutta (RK) time integration scheme that is used for temporal integration in simulation, from the 1st to 5th order by corresponding integer. Note that time_stepper = 3 specifies the total variation diminishing (TVD), third order RK scheme (Gottlieb and Shu <a class="el" href="citelist.html#CITEREF_gottlieb98">[18]</a>).</li>

<li>adap_dt activates the Strang operator splitting scheme which splits flux and source terms in time marching, and an adaptive time stepping strategy is implemented for the source term. It requires bubbles_euler = 'T', polytropic = 'T', adv_n = 'T' and time_stepper = 3. Additionally, it can be used with bubbles_lagrange = 'T' and time_stepper = 3. adap_dt_tol and adap_dt_max_iters are 1e-4 and 100, respectively, by default.</li>

<li>weno_order specifies the order of WENO scheme that is used for spatial reconstruction of variables by an integer of 1, 3, 5, and 7, that correspond to the 1st, 3rd, 5th, and 7th order, respectively.</li>

<li>weno_eps specifies the lower bound of the WENO nonlinear weights. It is recommended to set weno_eps to $10^{-6}$ for WENO-JS, and to $10^{-40}$ for other WENO variants.</li>

<li>mapped_weno activates the WENO-M scheme in place of the default WENO-JS scheme (Henrick et al. <a class="el" href="citelist.html#CITEREF_henrick05">[22]</a>). WENO-M a variant of the WENO scheme that remaps the nonlinear WENO-JS weights by assigning larger weights to non-smooth stencils, reducing dissipation compared to the default WENO-JS scheme, at the expense of higher computational cost. Only one of mapped_weno, wenoz, and teno can be activated.</li>

<li>wenoz activates the WENO-Z scheme in place of the default WENO-JS scheme (Borges et al. <a class="el" href="citelist.html#CITEREF_borges08">[6]</a>). WENO-Z is a variant of the WENO scheme that further reduces the dissipation compared to the WENO-M scheme. It has similar computational cost to the WENO-JS scheme.</li>

<li>wenoz_q specifies the power parameter q used in the WENO-Z scheme. It controls how aggressively the smoothness coefficients scale the weights. A higher value of wenoz_q increases the sensitivity to smoothness, improving stability but worsening numerical dissipation. For WENO3 and WENO5, q=1 is fixed, so wenoz_q must not be set. For WENO7, wenoz_q can be set to 2, 3, or 4.</li>

<li>teno activates the TENO scheme in place of the default WENO-JS scheme (Fu et al. <a class="el" href="citelist.html#CITEREF_fu16">[16]</a>). TENO is a variant of the ENO scheme that is the least dissipative, but could be less robust for extreme cases. It uses a threshold to identify smooth and non-smooth stencils, and applies optimal weights to the smooth stencils. Only available for weno_order = 5 and 7. Requires teno_CT to be set. Does not support grid stretching.</li>

<li>teno_CT specifies the threshold for the TENO scheme. This dimensionless constant, also known as $C_T$, sets a threshold to identify smooth and non-smooth stencils. Larger values make the scheme more robust but also more dissipative. A recommended value for teno_CT is 1e-6. When adjusting this parameter, it is recommended to try values like 1e-5 or 1e-7 for TENO5. A smaller value can be used for TENO7.</li>

<li>null_weights activates nullification of the nonlinear WENO weights at the buffer regions outside the domain boundaries when the Riemann extrapolation boundary condition is specified (bc_[x,y,z]%beg[end]} = -4).</li>

<li>mp_weno activates monotonicity preservation in the WENO reconstruction (MPWENO) such that the values of reconstructed variables do not reside outside the range spanned by WENO stencil (Balsara and Shu <a class="el" href="citelist.html#CITEREF_balsara00">[4]</a>; Suresh and Huynh <a class="el" href="citelist.html#CITEREF_suresh97">[50]</a>).</li>

<li>muscl_order specifies the order of the MUSCL scheme that is used for spatial reconstruction of variables by an integer of 1, or 2, that corresponds to the 1st, and 2nd order respectively. When using muscl_order = 2, muscl_lim must be defined.</li>

<li>muscl_lim specifies the slope limiter that is used in 2nd order MUSCL Reconstruction by an integer from 1 through 5. muscl_lim = 1, 2, 3, 4, and 5 correspond to minmod, monotonized central, Van Albada, Van Leer, and SUPERBEE, respectively.</li>

<li>muscl_eps controls the slope-product activation threshold for all MUSCL limiters. When not set (default), the threshold is 1e-9 for minmod/MC, and 1e-6 for others. Setting muscl_eps = 0 gives textbook limiter behavior where limiters activate whenever both slopes have the same sign.</li>

<li>int_comp activates interface compression using [1] THINC or [2] MTHINC (default off) used in variable reconstruction, with control parameters (ic_eps, and ic_beta).</li>

<li>riemann_solver specifies the choice of the Riemann solver that is used in simulation by an integer from 1 through 4. riemann_solver = 1, 2, and 3 correspond to HLL, HLLC, and Exact Riemann solver, respectively (Toro <a class="el" href="citelist.html#CITEREF_toro09">[56]</a>). riemann_solver = 4 is the HLLD solver for MHD or hypoelasticity simulations. For MHD it resolves 5 of the full seven-wave structure of the MHD equations (Miyoshi and Kusano <a class="el" href="citelist.html#CITEREF_miyoshi05">[37]</a>).</li>

<li>hll_u_interface: Selects between two HLL discretizations of volume fraction advection (riemann_solver = 1):<ul>

<li>Default ('F'): $\partial_t \alpha_k + u\,\partial_x \alpha_k = 0$</li>

<li>u-interface ('T', consistent with HLLC): $\partial_t \alpha_k + \partial_x(\alpha_k\, u) = \alpha_k\,\partial_x u$</li>

</ul>

</li>

<li>low_Mach specifies the choice of the low Mach number correction scheme for the HLLC Riemann solver. low_Mach = 0 is default value and does not apply any correction scheme. low_Mach = 1 and 2 apply the anti-dissipation pressure correction method (Chen et al. <a class="el" href="citelist.html#CITEREF_chen22">[11]</a>) and the improved velocity reconstruction method (Thornber et al. <a class="el" href="citelist.html#CITEREF_thornber08">[54]</a>). This feature requires model_eqns = 2 or 3. low_Mach = 1 works for riemann_solver = 1 and 2, but low_Mach = 2 only works for riemann_solver = 2.</li>

<li>avg_state specifies the choice of the method to compute averaged variables at the cell-boundaries from the left and the right states in the Riemann solver by an integer of 1 or 2. avg_state = 1 and 2 correspond to Roe- and arithmetic averages, respectively.</li>

<li>wave_speeds specifies the choice of the method to compute the left, right, and middle wave speeds in the Riemann solver by an integer of 1 and 2. wave_speeds = 1 and 2 correspond to the direct method (Batten et al. <a class="el" href="citelist.html#CITEREF_batten97">[5]</a>), and indirect method that approximates the pressures and velocity (Toro <a class="el" href="citelist.html#CITEREF_toro09">[56]</a>), respectively.</li>

<li>weno_Re_flux activates the scalar divergence theorem in computing the velocity gradients using WENO-reconstructed cell boundary values. If this option is false, velocity gradient is computed using finite difference scheme of order 2 which is independent of the WENO order.</li>

<li>weno_avg it activates the arithmetic average of the left and right, WENO-reconstructed, cell-boundary values. This option requires weno_Re_flux to be true because cell boundary values are only utilized when employing the scalar divergence method in the computation of velocity gradients.</li>

<li>surface_tension activates surface tension when set to 'T'. Requires sigma to be set and num_fluids. The color function in each patch should be assigned such that patch_icpp(i)%cf_val = 1 in patches where patch_icpp(i)%alpha = 1 - eps and patch_icpp(i)%cf_val = 0 in patches where patch_icpp(i)%alpha = eps.</li>

<li>viscous activates viscosity when set to 'T'. Requires Re(1) and Re(2) to be set.</li>

<li>hypoelasticity activates elastic stress calculations for fluid-solid interactions. Requires G to be set in fluid_pp, and fd_order to be set (1, 2, or 4). Compatible with HLL (riemann_solver = 1), HLLC (riemann_solver = 2), and HLLD (riemann_solver = 4). The Riemann solver choice determines how the elastic stress source term $\mathbf{S}^e$ is discretized:<ul>

<li>HLL: finite-difference velocity gradient (default), or interface-consistent velocity gradient when hypo_hll_interface_rhs = 'T' (matches HLLC).</li>

<li>HLLC: interface-consistent velocity gradient from the Riemann solution.</li>

<li>HLLD: dual-pass approach resolving the elastic wave structure. Requires 2D+ and exactly 2 fluid components.</li>

<li>With hypoelastic HLLD, use characteristic boundary conditions (bc_{x,y,z}%beg/end between -5 and -12) only where the domain boundary remains in a fluid region throughout the simulation. Keep material interfaces and solids out of the nearby cells used by the boundary calculation. A material present only at the numerical volume-fraction floor is allowed, even if it has nonzero G. These boundaries treat acoustic waves only. alt_soundspeed is supported.</li>

</ul>

</li>

<li>riemann_hypo_ADC: Enables anti-diffusion correction (ADC) for hypoelastic HLLC or HLLD. Blends the HLLC/HLLD flux locally toward the more diffusive HLL flux where a jump sensor (total normal stress, tangential velocity, and tangential stress) detects a strong contact or material interface, improving robustness and reducing interfacial overshoots. This trades contact and shear resolution for robustness where the sensor activates. ADC_kappa (default 1.0) scales the reference jump the sensor is normalized by; smaller values blend more toward HLL (more diffusive and robust). Off by default and recommended off: in MFC's tested hypoelastic cases, including strong shock-interface interactions, HLLD is stable and accurate without ADC. The option is a robustness fallback intended for regimes with intense shocks and intense shear at material interfaces.</li>

</ul>

Boundary Condition Patches</h4>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">num_bc_patches </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of boundary condition patches </td></tr>

<td class="markdownTableBodyRight">dir* </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Direction of the boundary patch. [1]: x; [2]: y; [3]: z </td></tr>

<td class="markdownTableBodyRight">loc* </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Location of the patch in the domain </td></tr>

<td class="markdownTableBodyRight">type* </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">The geometry of the patch. [1]: Line [2]: Circle [3]: Rectangle </td></tr>

<td class="markdownTableBodyRight">x[y,z]_centroid* </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Centroid of the boundary patch in the x[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">length_x[y,z]* </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Length of the boundary patch in the x[y,z]-direction </td></tr>

<td class="markdownTableBodyRight">radius* </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Radius of the boundary patch </td></tr>

</table>

*: These parameters should be prepended with patch_bc(j)% where $j$ is the patch index.

Boundary condition patches can be used with the following boundary condition types:<ul>

<li>-2 reflective</li>

<li>-3 ghost cell extrapolation</li>

<li>-17 Dirichlet</li>

</ul>

Line segments along each domain edge are supported for 2D simulations. Squares and circles on each face are supported for 3D simulations.

Constant Time-Stepping</h4>

<ul>

<li>dt specifies the constant time step size used in the simulation. The value of dt needs to be sufficiently small to satisfy the Courant-Friedrichs-Lewy (CFL) condition.</li>

<li>t_step_start and t_step_stop define the time steps at which the simulation starts and ends.</li>

</ul>

t_step_save is the time step interval for data output during simulation. To newly start the simulation, set t_step_start = 0. To restart the simulation from $k$-th time step, set t_step_start = k; see <a class="el" href="running.html" title="Running">Restarting Cases</a>. When t_step_start > 0, ./mfc.sh run skips pre_process by default, since it would otherwise overwrite the restart data being resumed from. Pass -t pre_process explicitly (as in the restart workflow) if regenerating it is intended.

Adaptive Time-Stepping</h5>

<ul>

<li>cfl_adap_dt enables adaptive time stepping with a constant CFL when true</li>

<li>cfl_const_dt enables constant dt time-stepping where dt results in a specified CFL for the initial condition</li>

<li>cfl_target specifies the target CFL value</li>

<li>n_start specifies the save file to start at</li>

<li>t_save specifies the time interval between data output during the simulation</li>

<li>t_stop specifies at what time the simulation should stop</li>

</ul>

To newly start the simulation, set n_start = 0. To restart the simulation from $k$-th time step, see <a class="el" href="running.html" title="Running">Restarting Cases</a>.

7. Formatted Output</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">format </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Output format. [1]: Silo-HDF5; [2] Binary </td></tr>

<td class="markdownTableBodyRight">precision </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">[1] Single; [2] Double </td></tr>

<td class="markdownTableBodyRight">parallel_io </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Parallel I/O </td></tr>

<td class="markdownTableBodyRight">file_per_process </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Whether or not to write one IO file per process </td></tr>

<td class="markdownTableBodyRight">cons_vars_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write conservative variables </td></tr>

<td class="markdownTableBodyRight">prim_vars_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write primitive variables </td></tr>

<td class="markdownTableBodyRight">alpha_rho_wrt(i) </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the partial density of the fluid $i$ to the database | </td></tr>

<td class="markdownTableBodyRight">rho_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the mixture density to the database </td></tr>

<td class="markdownTableBodyRight">mom_wrt(i) </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the $i$-direction momentum to the database </td></tr>

<td class="markdownTableBodyRight">vel_wrt(i) </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the $i$-direction velocity to the database </td></tr>

<td class="markdownTableBodyRight">E_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the total energy to the database </td></tr>

<td class="markdownTableBodyRight">pres_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the pressure to the database </td></tr>

<td class="markdownTableBodyRight">alpha_wrt(i) </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the volume fraction of fluid $i$ to the database </td></tr>

<td class="markdownTableBodyRight">gamma_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the specific heat ratio function to the database </td></tr>

<td class="markdownTableBodyRight">heat_ratio_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the specific heat ratio to the database </td></tr>

<td class="markdownTableBodyRight">ib_state_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Parameter to handle writing IB state on saves and outputting the state as a point mesh to SILO files. </td></tr>

<td class="markdownTableBodyRight">pi_inf_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the liquid stiffness function to the database </td></tr>

<td class="markdownTableBodyRight">pres_inf_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the liquid stiffness to the formatted database </td></tr>

<td class="markdownTableBodyRight">c_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the sound speed to the database </td></tr>

<td class="markdownTableBodyRight">T_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add each fluid's temperature to the database (needs cv > 0) </td></tr>

<td class="markdownTableBodyRight">omega_wrt(i) </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the $i$-direction vorticity to the database </td></tr>

<td class="markdownTableBodyRight">schlieren_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the numerical schlieren to the database </td></tr>

<td class="markdownTableBodyRight">qm_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the Q-criterion to the database </td></tr>

<td class="markdownTableBodyRight">liutex_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the Liutex to the database </td></tr>

<td class="markdownTableBodyRight">cf_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write color function field </td></tr>

<td class="markdownTableBodyRight">chem_wrt_T </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write temperature field for chemistry output </td></tr>

<td class="markdownTableBodyRight">fft_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Enable FFT output </td></tr>

<td class="markdownTableBodyRight">sim_data </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write interface and energy data files (post_process) </td></tr>

<td class="markdownTableBodyRight">down_sample </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Enable output downsampling </td></tr>

<td class="markdownTableBodyRight">fd_order </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Order of finite differences for computing the vorticity and the numerical Schlieren function [1,2,4] </td></tr>

<td class="markdownTableBodyRight">schlieren_alpha(i) </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Intensity of the numerical Schlieren computed via alpha(i) </td></tr>

<td class="markdownTableBodyRight">probe_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write the flow chosen probes data files for each time step </td></tr>

<td class="markdownTableBodyRight">num_probes </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of probes </td></tr>

<td class="markdownTableBodyRight">probe(i)%[x,y,z] </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Coordinates of probe $i$ </td></tr>

<td class="markdownTableBodyRight">output_partial_domain </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Output part of the domain </td></tr>

<td class="markdownTableBodyRight">[x,y,z]_output%beg </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Beginning of the output domain in the [x,y,z]-direction </td></tr>

<td class="markdownTableBodyRight">[x,y,z]_output%end </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">End of the output domain in the [x,y,z]-direction </td></tr>

<td class="markdownTableBodyRight">lag_txt_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write Lagrangian bubble data to .dat files </td></tr>

<td class="markdownTableBodyRight">lag_header </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write header to Lagrangian bubble .dat files </td></tr>

<td class="markdownTableBodyRight">lag_db_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Write Lagrangian bubble data to silo/hdf5 database files </td></tr>

<td class="markdownTableBodyRight">lag_id_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the global bubble idea to the database file </td></tr>

<td class="markdownTableBodyRight">lag_pos_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble position to the database file </td></tr>

<td class="markdownTableBodyRight">lag_pos_prev_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the previous bubble position to the database file </td></tr>

<td class="markdownTableBodyRight">lag_vel_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble translational velocity to the database file </td></tr>

<td class="markdownTableBodyRight">lag_rad_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble radius to the database file </td></tr>

<td class="markdownTableBodyRight">lag_rvel_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble radial velocity to the database file </td></tr>

<td class="markdownTableBodyRight">lag_r0_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble initial radius to the database file </td></tr>

<td class="markdownTableBodyRight">lag_rmax_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble maximum radius to the database file </td></tr>

<td class="markdownTableBodyRight">lag_rmin_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble minimum radius to the database file </td></tr>

<td class="markdownTableBodyRight">lag_dphidt_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble subgrid velocity potential to the database file </td></tr>

<td class="markdownTableBodyRight">lag_pres_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble pressure to the database file </td></tr>

<td class="markdownTableBodyRight">lag_mv_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble vapor mass to the database file </td></tr>

<td class="markdownTableBodyRight">lag_mg_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble gas mass to the database file </td></tr>

<td class="markdownTableBodyRight">lag_betaT_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble heat flux model coefficient to the database file </td></tr>

<td class="markdownTableBodyRight">lag_betaC_wrt </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Add the bubble mass flux model coefficient to the database file </td></tr>

</table>

The table lists formatted database output parameters. The parameters define variables that are outputted from simulation and file types and formats of data as well as options for post-processing.

<ul>

<li>format specifies the choice of the file format of data file outputted by MFC by an integer of 1 and 2. format = 1 and 2 correspond to Silo-HDF5 format and binary format, respectively. Both formats are supported by ./mfc.sh viz (see <a class="el" href="visualization.html" title="Flow visualization">Flow Visualization</a>). Silo-HDF5 requires the h5py Python package; binary has no extra dependencies.</li>

<li>precision specifies the choice of the floating-point format of the data file outputted by MFC by an integer of 1 and 2. precision = 1 and 2 correspond to single-precision and double-precision formats, respectively.</li>

<li>parallel_io activates parallel input/output (I/O) of data files. It is highly recommended to activate this option in a parallel environment. With parallel I/O, MFC inputs and outputs a single file throughout pre-process, simulation, and post-process, regardless of the number of processors used. Parallel I/O enables the use of different numbers of processors in each process (e.g., simulation data generated using 1000 processors can be post-processed using a single processor).</li>

<li>file_per_process deactivates shared file MPI-IO and activates file per process MPI-IO. The default behavior is to use a shared file. File per process is useful when running on >10K ranks. If file_per_process is true, then pre_process, simulation, and post_process must be run with the same number of ranks.</li>

<li>cons_vars_wrt and prim_vars_wrt activate the output of conservative and primitive state variables into the database.</li>

<li>[variable's name]_wrt activates the output of each specified variable into the database.</li>

<li>schlieren_alpha(i) specifies the intensity of the numerical Schlieren of $i$-th component. It must be specified for every fluid when schlieren_wrt is enabled.</li>

<li>fd_order specifies the order of the finite difference scheme used to compute the vorticity from the velocity field and the numerical schlieren from the density field using an integer of 1, 2, and 4. fd_order = 1, 2, and 4 correspond to the first, second, and fourth-order finite difference schemes.</li>

<li>probe_wrt activates the output of state variables at coordinates specified by probe(i)%[x;y,z].</li>

<li>ib_state_wrt is used to trigger post-processing of the IB state to be written out as a point mesh in the SILO files. When no IBs are moving, it also triggers force and torque calculation so that those values may be written to the output state files.</li>

<li>output_partial_domain activates the output of part of the domain specified by [x,y,z]_output%beg and [x,y,z]_output%end. This is useful for large domains where only a portion of the domain is of interest. It is not supported when precision = 1 and format = 1. It also cannot be enabled with flux_wrt, heat_ratio_wrt, pres_inf_wrt, c_wrt, omega_wrt, ib, schlieren_wrt, qm_wrt, or 'liutex_wrt'.</li>

</ul>

8. Acoustic Source</h3>

<th class="markdownTableHeadRight">Parameter </th><th class="markdownTableHeadCenter">Type </th><th class="markdownTableHeadLeft">Description </th></tr>

<td class="markdownTableBodyRight">acoustic_source </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Acoustic source module activation </td></tr>

<td class="markdownTableBodyRight">num_source </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Number of acoustic sources </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%support </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Geometry of spatial support for the acoustic source </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%dipole </td><td class="markdownTableBodyCenter">Logical </td><td class="markdownTableBodyLeft">Dipole source activation (optional; default = false -> monopole) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%loc(j) </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">$j$-th coordinate of the point that defines the acoustic source location </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%pulse </td><td class="markdownTableBodyCenter">Integer </td><td class="markdownTableBodyLeft">Acoustic wave form: [1] Sine [2] Gaussian [3] Square [4] Broadband </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%npulse </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Number of pulse cycles </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%mag </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Pulse magnitude </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%frequency </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Sine/Square - Frequency of the acoustic wave (exclusive) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%wavelength </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Sine/Square - Wavelength of the acoustic wave (exclusive) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%gauss_sigma_time </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Gaussian - Gaussian pulse time width in terms of sigma (exclusive) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%gauss_sigma_dist </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Gaussian - Gaussian pulse spatial width in terms of sigma (exclusive) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%delay </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Time delay of the acoustic wave (optional for %pulse = 1 or 3; default = 0) </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%dir </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Planer - Direction of acoustic propagation </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%length </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">2D/3D Planer - Spatial pulse length </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%height </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">3D Planer - Spatial pulse height </td></tr>

<td class="markdownTableBodyRight">acoustic(i)%foc_length </td><td class="markdownTableBodyCenter">Real </td><td class="markdownTableBodyLeft">Transducer - Focal length of the transducer </td></tr>

View remainder of file in raw view

Navigation Menu

Uh oh!

Uh oh!

FilesExpand file tree

case.html

Latest commit

History

case.html

File metadata and controls