MODFLOW and FEFLOW are both mature, well validated groundwater codes, and for a large class of problems either will give you a defensible answer. The choice between them is rarely about which is better. It is about whether your problem is one that finite differences handle comfortably, and about who has to accept the result.
A disclosure before the comparison, because it is relevant. Smart Bhujal is an authorised reseller of Aquaveo groundwater modeling software in India, and Aquaveo GMS is a graphical environment for MODFLOW among other codes. We have a commercial interest on one side of this comparison. Read the rest with that in mind, and note that we recommend FEFLOW below in the cases where it is the better tool.
The difference that actually matters
MODFLOW solves the groundwater flow equation with finite differences on a structured grid. FEFLOW uses finite elements on an unstructured mesh. Almost every practical distinction between them follows from that one choice.
A finite difference grid is made of rectangular cells. It is simple, fast, extremely well understood, and it represents an angled fault, a pinching-out layer or a curved shoreline by approximating it in steps. A finite element mesh can place its nodes where the geometry demands, so it fits complex boundaries and steep gradients without forcing you to refine the whole grid to get resolution in one place.
If your conceptual model is layered and your boundaries are reasonably regular, that flexibility buys you very little. If it is not, it buys you a great deal.
When MODFLOW is the right choice
MODFLOW is the default for most groundwater work, and defaults exist for good reasons.
- Regulatory and peer acceptance. It is developed by the USGS, it is free, the source is open, and a reviewer anywhere in the world will know it. If your result has to be defended to a regulator, a funder or an opposing expert, that pedigree is worth more than any feature.
- Layered aquifer systems. The problem MODFLOW was designed for, and still the shape of most real groundwater questions: a sequence of aquifers and aquitards, wells, rivers, recharge.
- Cost. The engine is free. You may pay for a graphical environment, but you are not paying for the solver, and for a budget-constrained programme that difference is decisive.
- The ecosystem. Decades of packages, documented benchmark problems, and a very large number of people who can pick your model up and run it. That last point matters more than it sounds when a project changes hands.
- Transport with the standard codes. Coupled with MT3DMS or its successors, contaminant transport is well trodden ground.
When FEFLOW earns its licence cost
FEFLOW is the better tool when the physics or the geometry goes beyond what a structured grid handles gracefully.
- Density-dependent flow. Saltwater intrusion in a coastal aquifer is the classic case. FEFLOW handles variable density natively and comfortably, and this is the single most common reason to prefer it.
- Complex geometry. Steeply dipping layers, faults, lenses that pinch out, or a domain where you need fine resolution in one small area and coarse everywhere else.
- Coupled heat transport. Ground source heat systems, thermal plumes, geothermal work.
- Detailed unsaturated zone behaviour. Where what happens above the water table is part of the question rather than a boundary condition.
Note that these are physical characteristics of the problem, not preferences. If you have saltwater intrusion, the choice is largely made for you.
The GUI is a separate decision
People often compare FEFLOW against MODFLOW when they are actually comparing FEFLOW against a MODFLOW interface, and those are different comparisons.
MODFLOW is an engine. You drive it through something: ModelMuse from the USGS, which is free; Aquaveo GMS; Visual MODFLOW; or scripted with Python and FloPy. FEFLOW is sold as an integrated environment, so the engine and the interface arrive together. Part of what a FEFLOW licence buys is the interface, and part of what a MODFLOW workflow costs is choosing and paying for one.
If the friction you are feeling is with a clumsy interface rather than with the solver, switching engines is an expensive way to solve a tooling problem.
What neither of them fixes
Both codes will solve the equations you give them, correctly, on the data you supply. Neither will tell you that your observation record has a two year gap that somebody interpolated across, or that your conceptual model has the wrong number of layers.
In practice the error in a groundwater prediction is dominated by conceptual model and data quality rather than by the numerical scheme. We have written separately about why gap filling has to happen before calibration rather than after, and the same argument applies here. A model in the wrong code with good data will beat a model in the right code with bad data, most of the time.
A short decision rule
Ask three questions. Does the problem involve variable density, coupled heat, or geometry that a rectangular grid would badly misrepresent? Does the result have to survive regulatory or adversarial review? And is there budget for a commercial licence?
If the first is yes, use FEFLOW. If the first is no and the second is yes, use MODFLOW. If the first is no and the third is no, use MODFLOW with ModelMuse and spend the saved money on field data, which will improve your answer more than either code will.
We build groundwater models in both, and the choice is made per project rather than by house preference. If you are scoping work and are not sure which side of that line you are on, that is a short conversation and part of what our consulting and modelling services are for. Where the model is going to end up inside something an institution operates day to day, it becomes a decision support system rather than a study, which changes the answer again.