Hi. I can help you if you are looking to build on Linux.
Anyway, in any operating system, you should follow the Blender manual instructions:
https://wiki.blender.org/wiki/Building_Blender
Once you have managed to build master branch (that is, to make sure everything is working correctly), to change to mantaflow branch you should do:
git checkout fluid-mantaflow
git pull
And build.
Wow, so easy. Thanks.
I made a copy. Here is the Link.
For which OS and OS version? If this is for Linux, it is not a portable build. That is, it will only work in a system which has the same versions of dependencies in which it has been compiled.
It is not easy to build portable builds for Linux.
Hi,
it is Ubuntu 18.10 
Yafu, tried to say that you need to do a statically linked build in order to have other people use it.
If you havenāt itās pretty much pointless to upload your build. Even if the downloader has the same Ubuntu version as you he would still need the same build environment. If he has heās probably already building blender himself.
This makes me think about this now that Mantaflow is being reviewed:
Is the plan keeping both Elbeem and Mantaflow? Or will Mantaflow replace current fluid and smoke simulations? Iām not sure if we can currently do with Mantaflow what current Smoke and Fluid simulation are capable of.
Hi, there is a new Version. It is from the last satursday.
/
In theory, same basic features are available.
In practice, tweaking of values, caching and behavior is different.
The whole thread was about feedback on mantaflow branch.
If you are encountering problems or worrying about a potential insufficiency of Mantaflow, just define them as clearly as possible, here.
If sebbas and nils are not aware of the issue, there is no chance they could solve it.
Firstly, I just want to say that Iām pretty excited about this branch, and have seen promising results during my fiddlings. That said, Iāve encountered 2 strange issues using mantaflow.
The first issue is when using subframes on a smoke flow object, the baked smoke sometimes ājumpsā ahead of the flow object, like itās skipped some frames or something. I think it has to do with the modifiers I have on the object (subsurf and displace) because when I deleted them, it seemed to solve the problem. Not necessarily a showstopper, but a problem nonetheless.
The second issue is more problematic. Mantaflow doesnāt seem to recognize any forces acting upon the smoke until 14 frames into the simulation. This includes turbulence fields as well as itās own built-in āvorticityā setting. On every sim Iāve run, the smoke has no forces acting on it for the first 13 frames, then suddenly it starts moving around the way I want it to. Can anyone confirm this? Is there some way to fix that?
After quick tests, I can say No.
I donāt have those problems on linux with a fresh build.
Maybe what you wanted to do can be done by using displacement on a guide object instead of flow object.
That looks a little bit like an outdated cache that was not correctly cleared.
Try to modify a value of domain to force cache erasing.
Iām on Windows with the newest build, and I do have those problems.
Iām not sure how guide objects work, but I kinda doubt mantaflow is supposed to not work properly when using subframes and modifiers simultaneously, so it seems like a problem regardless.
No, itās got nothing to do with the cache. Iāve made numerous changes to the domain in an effort to get to the bottom of it, unbaking and rebaking in the process.
Hereās some screenshots illustrating the problem.
As you can see, for the first 14 or so frames, it seems that no forces are at work on the simulation. Then they do kick in, slowly, giving me the effect I want, but much later than I want it. The effect is even more dramatic with stronger force field settings (which is how I discovered this problem).
Well, it is difficult to understand if something went wrong from such screen captures.
Normally, smoke and flames are supposed to rise vertically, not in such direction.
Did you gave initial velocity to flow ?
A gas is a fluid. It is a lot related to its mass, its density.
At first frame of simulation, there is this initial mass corresponding to Suzanne volume that will continue to influence the rest of simulation and that is pushed away by progressive income of gas flow.
We can distinguish Suzanne shape at top right corner of your first screenshot.
And it looks like your problem began to resolved when this mass is evacuated out of domain.
So, try to disable Absolute Density option of Inflow, to reduce initial velocities of inflow or use another force field for that.
There are lots of settings that can control smoke flow, and flames reaction inside domain settings.
I donāt know what you want to obtain.
But trying to make a Wind field compete with initial veolcities, 2 directional forces to obtain a noisier flow that bends itself : it is not the best approach.
I would play with vorticity, speed of flames and noise instead.
If I really need 2 directional forces. I would animate force fields. They are influencing the whole smoke, not just voxels corresponding to present emission. So, force fields effect would be more predictatble.
And you can be sure which one has the priority, the bigger strength at which moment.
The smoke is rising vertically at first, my flow object is animated from the upper left to the lower right to better illustrate when the force field effect kicks in. Thatās why the smoke appears to be flowing up and to the left.
All flow and domain settings are at default. There is no wind force, only a single turbulent force. And as you can see, it has no effect for the first part of the simulation.
When someone detects a problem, better share the .blend file and the description about how to reproduce the problem. Maybe @sebbas is reading the thread.
I have also seen that some have reported problems related to mantaflow in the tracker, but I am not sure if we are all allowed to do so.
I didnāt save a blend file originally because the steps to recreate the problem are as simple as it gets, using default settings (except setting flow object to āinflowā). But at your requestā¦
mantaflow_turbulence_issue.blend (711.1 KB)
Iām on windows 10 64 bit using newest mantaflow build as of today.
Yep, no matter how simple the scene looks, it is always better to share the file to be better analyzed, mainly when it should be analyzed by the developers.
Regarding the problem that you mention of force fields, apparently it does not happen that it starts working from a certain frame number, but apparently it starts to work a lot weaker at the beginning. You can see it better with wind field:
mantaflow_turbulence_issue_mod.blend (714.0 KB)
Even in the first frame the fire makes an attempt to move up, but Iām not really sure if this is a configuration problem (Iām not sure if influence curve can be configured from somewhere) or if it is a bug.
I agree that the effect of the force field seems to āramp upā over timeā¦but I only see this problem using mantaflow. In regular blender the force fields take effect immediately. Is this just a limitation of mantaflow, or is it not working the way itās supposed to? I donāt know, but I find it a bit of an inconvenience. Which is sad, because I really love it so far otherwise.
I do not know, just describe what we assume are problems, with the hope that @sebbas will read the messages and determine if there really is a problem.
With the inverse animation it is more difficult to detect the problem, I am not sure if this could depend on the distance to the force field in mantaflow.
mantaflow_turbulence_issue_mod_invert.blend (716.1 KB)
I considered distance being a factorā¦my original project had the force field outside the domain by about a blender unit. I later moved it inside the domain, in the center, to see if that would help, but I saw no difference. 
Your first intuition was probably the best one.
Mantaflowās domain has its own subframes settings.
By default, CFL number is set to 4 to allow a quick baking. It is sufficient for a non-moving emitter.
If you decrease it, you should obtain something closer to official blender with first frames affected by turbulence.
