matlablbm代码-lbm-c:自动从code.google.com/p/lbm-c导出

  • C4_954990
    了解作者
  • 7.9MB
    文件大小
  • zip
    文件格式
  • 0
    收藏次数
  • VIP专享
    资源类型
  • 0
    下载次数
  • 2022-05-09 23:24
    上传日期
Matlab lbm代码概述 当前版本:0.1 LBM-C是使用nVidia的CUDA平台实现的格子Boltzmann 2D和3D流体流动求解器。 LBM-C是用CUDA C编写的,并根据GPL v2进行了许可,欢迎您自行决定使用,更改和改进LBM-C。 此开放源代码的目标是: 提供基于CUDA的直接实现的格子Boltzmann方法,用于对流体流动进行建模 通过开放源代码的本质鼓励协作 出于CFD(计算流体动力学)的目的,行使图形硬件的功能 如果您希望为LBM-C做出贡献,那么LBM-C谷歌小组就是一个不错的起点。 特征 可以通过使用简单的Matlab界面来配置模型 输入常量通过ASCII输入文件指定 CGNS格式的输入数据(与大多数后处理器兼容,尽管输入数据格式与cgns不兼容) 以CGNS格式输出数据(与大多数后处理器兼容) 建模能力 可以通过使用全程反弹或任意简化的Nobel&Torczynski浸入式移动边界方法来考虑任意几何形状。 如Feng等人所证明的,使用这种边界条件可以与离散元素方法(尚未实现)进行简单的耦合。 人 使用Zhou&He的压力边界条件可以在边界上施加边界压
lbm-c-master.zip
内容介绍
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Copyright by The HDF Group. * * Copyright by the Board of Trustees of the University of Illinois. * * All rights reserved. * * * * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the files COPYING and Copyright.html. COPYING can be found at the root * * of the source code distribution tree; Copyright.html can be found at the * * root level of an installed copy of the electronic HDF5 document set and * * is linked from the top-level documents page. It can also be found at * * http://hdfgroup.org/HDF5/doc/Copyright.html. If you do not have * * access to either file, you may request a copy from help@hdfgroup.org. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ /* * Programmer: John Mainzer -- 10/12/04 * * Purpose: This file contains declarations which are normally visible * only within the H5C package. * * Source files outside the H5C package should include * H5Cprivate.h instead. * * The one exception to this rule is test/cache.c. The test * code is easier to write if it can look at the cache's * internal data structures. Indeed, this is the main * reason why this file was created. */ #ifndef H5C_PACKAGE #error "Do not include this file outside the H5C package!" #endif #ifndef _H5Cpkg_H #define _H5Cpkg_H /* Get package's private header */ #include "H5Cprivate.h" /* Get needed headers */ #include "H5SLprivate.h" /* Skip lists */ /* With the introduction of the fractal heap, it is now possible for * entries to be dirtied, resized, and/or moved in the flush callbacks. * As a result, on flushes, it may be necessary to make multiple passes * through the slist before it is empty. The H5C__MAX_PASSES_ON_FLUSH * #define is used to set an upper limit on the number of passes. * The current value was obtained via personal communication with * Quincey. I have applied a fudge factor of 2. * * -- JRM */ #define H5C__MAX_PASSES_ON_FLUSH 4 /**************************************************************************** * * structure H5C_t * * Catchall structure for all variables specific to an instance of the cache. * * While the individual fields of the structure are discussed below, the * following overview may be helpful. * * Entries in the cache are stored in an instance of H5TB_TREE, indexed on * the entry's disk address. While the H5TB_TREE is less efficient than * hash table, it keeps the entries in address sorted order. As flushes * in parallel mode are more efficient if they are issued in increasing * address order, this is a significant benefit. Also the H5TB_TREE code * was readily available, which reduced development time. * * While the cache was designed with multiple replacement policies in mind, * at present only a modified form of LRU is supported. * * JRM - 4/26/04 * * Profiling has indicated that searches in the instance of H5TB_TREE are * too expensive. To deal with this issue, I have augmented the cache * with a hash table in which all entries will be stored. Given the * advantages of flushing entries in increasing address order, the TBBT * is retained, but only dirty entries are stored in it. At least for * now, we will leave entries in the TBBT after they are flushed. * * Note that index_size and index_len now refer to the total size of * and number of entries in the hash table. * * JRM - 7/19/04 * * The TBBT has since been replaced with a skip list. This change * greatly predates this note. * * JRM - 9/26/05 * * magic: Unsigned 32 bit integer always set to H5C__H5C_T_MAGIC. * This field is used to validate pointers to instances of * H5C_t. * * flush_in_progress: Boolean flag indicating whether a flush is in * progress. * * trace_file_ptr: File pointer pointing to the trace file, which is used * to record cache operations for use in simulations and design * studies. This field will usually be NULL, indicating that * no trace file should be recorded. * * Since much of the code supporting the parallel metadata * cache is in H5AC, we don't write the trace file from * H5C. Instead, H5AC reads the trace_file_ptr as needed. * * When we get to using H5C in other places, we may add * code to write trace file data at the H5C level as well. * * aux_ptr: Pointer to void used to allow wrapper code to associate * its data with an instance of H5C_t. The H5C cache code * sets this field to NULL, and otherwise leaves it alone. * * max_type_id: Integer field containing the maximum type id number assigned * to a type of entry in the cache. All type ids from 0 to * max_type_id inclusive must be defined. The names of the * types are stored in the type_name_table discussed below, and * indexed by the ids. * * type_name_table_ptr: Pointer to an array of pointer to char of length * max_type_id + 1. The strings pointed to by the entries * in the array are the names of the entry types associated * with the indexing type IDs. * * max_cache_size: Nominal maximum number of bytes that may be stored in the * cache. This value should be viewed as a soft limit, as the * cache can exceed this value under the following circumstances: * * a) All entries in the cache are protected, and the cache is * asked to insert a new entry. In this case the new entry * will be created. If this causes the cache to exceed * max_cache_size, it will do so. The cache will attempt * to reduce its size as entries are unprotected. * * b) When running in parallel mode, the cache may not be * permitted to flush a dirty entry in response to a read. * If there are no clean entries available to evict, the * cache will exceed its maximum size. Again the cache * will attempt to reduce its size to the max_cache_size * limit on the next cache write. * * c) When an entry increases in size, the cache may exceed * the max_cache_size limit until the next time the cache * attempts to load or insert an entry. * * min_clean_size: Nominal minimum number of clean bytes in the cache. * The cache attempts to maintain this number of bytes of * clean data so as to avoid case b) above. Again, this is * a soft limit. * * * In addition to the call back functions required for each entry, the * cache requires the following call back functions for this instance of * the cache as a whole: * * check_write_permitted: In certain applications, the cache may not * be allowed to write to disk at certain time. If specified, * the check_write_permitted function is used to determine if * a write is permissible at any given point in time. * * If no such function is specified (i.e. this field is NULL), * the cache uses the following write_permitted field to * determine whether writes are permitted. * * write_permitted: If check_write_permitted is NULL, this boolean flag * indicates whether writes are permitted. * * log_flush: If provided, this function is called whenever a dirty * entry is flushed to disk. * * * In cases where memory is plentiful, and performance is an issue, it * is useful to disable all cache evictions, and thereby postpone metadata * writes. The following fi
评论
    相关推荐