calebbell / fluids Goto Github PK

For Reynolds calculation function, I think there is a mistake between kinematic and dynamic viscosity.

see: https://en.wikipedia.org/wiki/Reynolds_number

Reynolds(V, D, rho=None, mu=None, nu=None)

Calculates Reynolds number or Re for a fluid with the given
properties for the specified velocity and diameter.

Inputs either of any of the following sets:

• V, D, density rho and kinematic viscosity mu
• V, D, and dynamic viscosity nu

Would be a really nice addition to the library. This is equation 1-43 in Crane
TP 410 with accompanying charts on A-23. Cited in the bibliography:

Shapiro, A. H. (1953). The Dynamics and Thermodynamics of Compressible Fluid
Flow. John Wiley & Sons.

If you're amenable to inclusion of something like this in the package, I
might take a stab at it myself when I get a chance.

Hi Caleb,

It would be good to have similar functionality to the piping schedule database functions you have but for piping fitting dimensions. It would be great to see fitting databases much like Pipedata-Pro (https://www.pipedata.com/10-Software/01-Pipedata-Pro/DataSummary/) implemented in this library so they can be pulled directly into calculations and assessments similar to the "nearest_pipe" function for for dimensions, weights, etc for flanges, elbows, etc.

Context:
First off, amazing work here. I am currently trying testing this on an implementation of MicroPython (through ndless support, not native) on a TI-Nspire CAS CX as I have been looking for a way to run this type of analysis and have a database of piping on my handheld. I haven't done extensive testing but most of the features I have tested so far work on the platform and I am just working on how I can make it useful for myself (ie either need to make myself a front end to do full analysis in MicroPython or find a way to MicroPython to export results to somewhere the calculator can pick up and bring into the rest of my analysis tools already on calc). My model only has aftermarket support for python which is a double-edged sword as it makes it somewhat more versatile than the TI supported implementation on the CXII but it also cuts off direct integration into the main calculator functions.

I think that there may be an issue in the calculation of G, when calculating the K-factor for the branch of a diverging Tee.

G is determined according to the following pseudocode:

if angle < 75:
    if beta2 <= 0.35:
        if` Q_ratio <= 0.4:
            G = 1.1 - 0.7*Q_ratio
        else:
            G = 0.85
    else:
        if Q_ratio <= 0.6:
            G = 1.0 - 0.6*Q_ratio
        else:
            G = 0.6
else:
    if beta2 <= 2/3.:
        G = 1
    else:
        G = 1 + 0.3*Q_ratio*Q_ratio

The "angle<75" condition isn't mentioned in crane (to my knowledge), so G should only determined by the following part of the code:

if beta2 <= 0.35:
      if Q_ratio <= 0.4:
          G = 1.1 - 0.7*Q_ratio
      else:
          G = 0.85
  else:
      if Q_ratio <= 0.6:
          G = 1.0 - 0.6*Q_ratio
      else:
          G = 0.6

Could you please tell me where the angle<75 condition came from?

Hi,

I've started using your library to convert size distributions of nanoparticles across different basis (mass <-> surface <-> number). Somehow I have a mismatch between the input data (artificial distribution with 2 modes, equally-represented in mass) and the output plots (result of ParticleSizeDistribution.plot_pdf):

• the height of the modes in the mass-weighted fractions changes (the input fractions were normalized, so there should be no change)
• with a bimodal distribution, the proportions of the 2 modes provided as input on a mass basis correspond to the plot of the pdf in surface basis... I've provided a minimal example below.

The first issue could be related to a lack of renormalization of the fractions by the bin width (that would introduce a scaling factor over the whole pdf). For the 2nd issue, I've been browsing the code but could find why.
Thanks for your help.

Cheers,
Bertrand

See minimal example here:
https://gist.github.com/bertrand-faure/701fe217104a26b4bcc6ffb4c46c2b31

It would be nice if setuptools was supported so its features beyond distutils could be used, e.g. building eggs. I'd be willing to implement this, but I thought I might create an issue first to make sure there's interest in merging it.

Hi, the files tests/__init__.py and tests/nrlmsise00/__init__.py are GPL-3 licensed which I figure is a mistake with the rest of the library being MIT licensed.

Hi 👊

This is my first visit to this fine repo, but it seems you have been working hard to keep all dependencies updated so far.

Once you have closed this issue, I'll create seperate pull requests for every update as soon as I find one.

That's it for now!

Happy merging! 🤖

Trying to build from scratch latest release on Debian/Testing with python 3.8
I had some issues with running the tests with python3.8 -m pytest tests:

============================= test session starts ==============================
platform linux -- Python 3.8.6, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
rootdir: /build/fluids-0.1.86, inifile: pytest.ini
plugins: cov-2.8.1
collected 558 items / 35 errors / 523 selected

==================================== ERRORS ====================================
____ ERROR collecting .pybuild/cpython3_3.8_fluids/build/tests/__init__.py _____
/usr/lib/python3/dist-packages/_pytest/runner.py:226: in from_call
    result = func()
/usr/lib/python3/dist-packages/_pytest/runner.py:253: in <lambda>
    call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
/usr/lib/python3/dist-packages/_pytest/doctest.py:432: in collect
    optionflags = get_optionflags(self)
/usr/lib/python3/dist-packages/_pytest/doctest.py:302: in get_optionflags
    flag_acc |= flag_lookup_table[flag]
E   KeyError: 'NUMBER'
_ ERROR collecting .pybuild/cpython3_3.8_fluids/build/tests/test_atmosphere.py _
/usr/lib/python3/dist-packages/_pytest/runner.py:226: in from_call
    result = func()
/usr/lib/python3/dist-packages/_pytest/runner.py:253: in <lambda>
    call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
/usr/lib/python3/dist-packages/_pytest/doctest.py:432: in collect
    optionflags = get_optionflags(self)
/usr/lib/python3/dist-packages/_pytest/doctest.py:302: in get_optionflags
    flag_acc |= flag_lookup_table[flag]
E   KeyError: 'NUMBER'
...

Any hint to solve this problem would be great.
Thanks

Hi,

what would be the recommended method for computing the pressure drop of a simple throttle plate in a pipe? I have flow conditions and D, Do.

For example, using an orifice correlation at 10lpm, water approx.

discharge = C_Reader_Harris_Gallagher(16e-3, 8e-3, 1000, 1000 * 1e-6, 10 / 60000 * 1000)
K = discharge_coefficient_to_K(16e-3, 8e-3, discharge)

K
Out[29]: 28.15866270889264

this seems pretty high but as I understand is the K-value connected to reoverable and non-recoverable pressure drop. For compressible media, one could compute dP and then use a correlation for the non-recoverable part. I could do the same for incomp. media but I wonder if there's an easier way...

First time a Stream is initiated, there is something wrong with density calculations (s.rho)
After first initiation, the calculations are correct.
Example:
p=883e5
t=443
flow=0
gas = 'methane'
s = Stream(gas, m=flow, T=t, P=p)
s.rho
>>> 252.6545813242718
s = Stream(gas, m=flow, T=t, P=p)
s.rho
>>> 273.0034921582086
s = Stream(gas, m=flow, T=t, P=p)
s.rho
>>> 273.0034921582086

Hi Caleb,

I ran into an issue using pint units with certain Crane fittings methods, which required me to convert to meters and strip the magnitude out.

K_gate_valve_Crane, K_globe_valve_Crane , bend_rounded_Crane gave me the issues, but there may be others. All three raised a ValueError that traces back to friction.ft_Crane(D) line 1847, which compares the input diameter to 1e-2 as a float.

I'm willing to give a shot at fixing this myself as it's a tiny issue, but I have 0 idea how GitHub works. Do I make a pull request? Then test out some ways to fix the issue in an environment on my machine, then...what?

BTW I am using fluids for some heating coil and hydraulic circuit design using a heat transfer fluid. It is working quite nicely with some custom fits to the fluid manufacturer's tabulated property data.

Is it possible that V_from_h() of a vertical torispherical tank gets numerically unstable at the very tank top? My guess is V_vertical_torispherical().

My current workaround is not to use .V_total and limit queried heights at e.g. 0.9999*h_max.

Version:
conda-forge/noarch::fluids-0.1.75-py_1

Code to reproduce the problem:

>>> import fluids as fd
>>> Tk = fd.TANK(L=3, D=5, horizontal=False, 
...     sideA='torispherical', sideA_f=1, sideA_k=0.1,
...     sideB='torispherical', sideB_f=1, sideB_k=0.1) #DIN28011
>>> 
>>> print(Tk.V_total)
90.29935171486848
>>> print(Tk.V_from_h(0.99999*Tk.h_max))
83.64636099603153
>>> print(Tk.V_total/2)
45.14967585743424
>>> print(Tk.V_from_h(0.50000*Tk.h_max))
41.82318051716474

Hi,

nice tool great work

Is it possible to implement a further pipe diameter type? aka EN10255

Ref: https://lgtm.com/projects/g/CalebBell/fluids/?mode=tree&ruleFocus=900075

When the isentropic exponent is given as exactly 1 for meters of the type that call nozzle_expansibility (https://github.com/CalebBell/fluids/blob/master/fluids/flow_meter.py#L1306) a division by zero error occurs. This is due to the /(k-1) factor on the following line. https://github.com/CalebBell/fluids/blob/master/fluids/flow_meter.py#L1363

This function is called by the following meter types.
HOLLINGSHEAD_WEDGE
HOLLINGSHEAD_VENTURI_SMOOTH
HOLLINGSHEAD_VENTURI_SHARP
WEDGE_METER
MACHINED_CONVERGENT_VENTURI_TUBE
LONG_RADIUS_NOZZLE
MILLER_CONICAL_ORIFICE
ISO_15377_CONICAL_ORIFICE
ISA_1932_NOZZLE
VENTURI_NOZZLE
AS_CAST_VENTURI_TUBE
MACHINED_CONVERGENT_VENTURI_TUBE
ROUGH_WELDED_CONVERGENT_VENTURI_TUBE

line 2507: the model name "Beggs-Brill" might be revised as "Beggs_Brill"

Hello! Very nice and useful library you wrote.
I think this (Symmetric diverging\converging tees K calculation) feature is needed to complete the tees calculations covering all possible cases.
Thanks.

In the differential_pressure_meter_solver function, the return from differential_pressure_meter_C_epsilon is assigned to (epsilon, C) while the return from the function is the same order as the function's title, which is (C, epsilon).

This could lead to large error in the calculated flow rate across the orifice plate.
(The error was only 1% in my test case)

Hi Caleb,
I ran into a possible issue when utilizing the differential_pressure_meter_solver in fluids.flow_meter.

If I chose the 'long radius nozzle', without specifying the discharge coefficient, I get a math domain error.
Since the discharge coefficient is a function of Reynolds number (ISO 5167-3), the 'long radius nozzle' is solved by an iteration.
In the third iteration step, the mass flow "guess" becomes negative, resulting in a negative Reynolds number and hence an error from square root of a negative number.

I am able to calculate discharge coefficient for a given mass flow rate using either C_long_radius_nozzle or differential_pressure_meter_C_epsilon function. So the problem appears to be related to the iteration process resulting in a negative mass flow at some point.

Example:

import fluids

InputDict = {'D': 0.36,
             'rho': 39.6,
             'mu': 1.32e-05,
             'k': 1.3,
             'D2': 0.28,
             'P1': 5000000.0,
             'P2': 4995000.0,
             'meter_type': 'long radius nozzle'}


specified_massflow = 47 #kg/s
C_long_radius_nozzle = fluids.flow_meter.C_long_radius_nozzle(InputDict['D'], InputDict['D2'], InputDict['rho'], InputDict['mu'], specified_massflow)

print('C = ',C_long_radius_nozzle)


massflow = fluids.flow_meter.differential_pressure_meter_solver(InputDict['D'], InputDict['rho'], 
                                                                InputDict['mu'], InputDict['k'], 
                                                                InputDict['D2'], InputDict['P1'], 
                                                                InputDict['P2'], meter_type=InputDict['meter_type'])

1. friction_plate_Martin_1999(Re, plate_enlargement_factor)

The second parameter of this function should be named chevron_angle (in radians) and not plate_enlargement_factor.

In Martin's equations an uppercase phi, $\Phi$, denotes the plate enlargement factor whereas a lowercase phi, $\phi$, denotes the chevron angle. The equations in the source code are correct, it's just the name of the parameter which is wrong or misleading.

Note, that chevron_angle must be given in radians here, whereas in friction_plate_Kumar() it is given in degree.

2. friction_plate_Martin_VDI(Re, plate_enlargement_factor)

1. Same as for friction_plate_Martin_VDI(). Second parameter should be named chevron_angle.

2. The equations for friction_plate_Martin_1999() and friction_plate_Martin_VDI() are almost the same. friction_plate_Martin_1999() calculates the Fanning friction factor and multiplies the result by 4 to return the Darcy friction factor, whereas friction_plate_Martin_VDI() calculates the Darcy friction factor directly. But there's one small discrepancy:
   In Martin 1999 the term 0.045⋅tanφ (in Fanning notation) would be 0.18⋅tanφ in Darcy notation, but in friction_plate_Martin_VDI() it is 0.28⋅tanφ. Is this a typo? According to the Heat Atlas, 2010, 2nd edition, the term 0.18⋅tanφ is correct. (But then friction_plate_Martin_1999() and friction_plate_Martin_VDI() calculate exactly the same.)

3. friction_plate_Kumar(Re, chevron_angle)

I believe chevron_angle in Kumar's equation is an angle with respect to the horizontal axis and not the vertical axis, as stated in the documentation. This is in contrast to Martin's equations where chevron_angle is an angle with respect to the vertical axis.

Thanks for pulling together this awesome tool! Is it possible to implement another method in entrance_distance for Crane or maybe create an entrance_distance_Crane function? The Crane Handbook indicates inward projections have a K = 0.78.

Thanks,

MT

I think the formula in fluids.fittings.contraction_conical for Kfr,2 is wrong, the num. and the denum. excl. the friction factor should be switched.

From https://fluids.readthedocs.io/fluids.geometry.html#module-fluids.geometry:

sideA_f : Dish-radius parameter for side A; fD = dish radius [1/m]

Shouldn't f and k be dimensionless? Then fD is in [m], just like D.

Hi there

I just stumbled across what I think is a misstake in your equation for the explicit Haaland expression in friction_factor. I do have both sources that you cite and Haaland himself states -1.8 to be the constant before the log. However in Winnings work the formulation is given with a -3.6 factor. Winning directly cites Haaland so I believe it might be a typo in Winnings work.

Cheers

I noticed that the average compression factor defaults to 1, but this is not accurate. Is there any other way to auto calculate the average compression factor。

A common situation involves a vertical liquid-phase reactor / tower, where gas bubbles are evolving (or being consumed) throughout the tower at some exogenous rate "rate(height, T, P, x̄ )" and ascending at a different rate from the liquid's flowrate (possibly passing through mixing trays), to form a controlled gas pocket of variable volume at the top of the tower. This may be (but is not necessarily) a fluidized bed reactor.

While fluids has some two-phase functions, it lacks functions for the prediction of bubble diameters, evolution of bubble diameters, & ascension rates. Some solved problems for vertical and horizontal two-phase flow would be welcome as well.

Shouldn't be the function mean_size_ISO be used instead of mean_size in the examples given in the tutorial for particle size distributions?

In the following lines, the SMD would otherwise be psd.mean_size(3,2) and not psd.mean_size(1,2).

It would be nice if the usage of math.sqrt would be replaced by the use of np.sqrt().

If one is to evaluate Arrays of Data the math.sqrt() Function will raise:
TypeError: cannot convert the series to <class 'float'>
even though a series with the type of float is given.

It would make using the fluid module more convenient.

Hi,

Thanks for sharing all your code! I was interested in using some of your functions, but I found you do not have everything set up do be able to work with arrays. For example, you cannot do:

fluids.friction.Haaland(np.array([1e5, 2e5, 3e5]), 0.0001/0.01)

because Haaland uses log10 from math instead of numpy. Is there a reason you chose to use math instead of numpy?

Miles

Dear Caleb,

It is a great tool that you have developed!

I am currently working with the Hooper method for a conical diffuser/expansion from the fluids.fittings library. I think there is a small error for the case of Re_1 < 4000 and angle < 45°. It returns K = K_sharp while it should return K = K_sharp2.6sin(angle/2).

Code is stated below:
elif method == 'Hooper':
if Re is None:
raise ValueError("Method Hooper requires Reynolds number")
if Re < 4000.0:
return 2.0*(1.0 - betabetabetabeta) # Not the same formula as Rennels
if fd is None:
fd = Clamond(Re=Re, eD=roughness/Di1)
x = 1.0 - betabeta
K = (1.0 + 0.8fd)xx
if angle_rad > 0.25pi:
return K
return K2.6sin(0.5*angle_rad)

Best regards,
Allan

When using fluids.numba it will set the file path of the function in numba_exec_cacheable to "<ipython-%s>" which will make Numba fallback to _IPythonCacheLocator which will again import from IPython.paths import get_ipython_cache_dir.

It feels that having the IPython dependency for caching is too big of a hammer, since any library that depends on fluids now need to take a direct dependency on ipython as well. Is there a way to avoid the IPython dependency and still use Fluids with Numba?

Hi. I am working with a lot of arrays for design studies and would love to use fluids. My first application case uses your friction_factor function. Unfortunately it seems that I can only calculate one value at a time. As I would like to avoid looping over my entire array it would be great if you could implement ndarray functionality to the friction_factor module.

Cheers